> ## Documentation Index
> Fetch the complete documentation index at: https://docs.devias.io/llms.txt
> Use this file to discover all available pages before exploring further.

> ## Agent Instructions
> The docs are served at https://docs.devias.io. Every path in these docs is relative to that root: /llms.txt is https://docs.devias.io/llms.txt.
> Devias is an open-source platform that works as an operating system for a business: a core (records, views, workflows, agents, permissions) with installable modules.
> Pages are typed by folder. concepts/ explains what things are, guides/ gives procedures, reference/ is exhaustive (SDK, CLI, HTTP API), operate/ covers hosting. Use /start/glossary for exact terms.
> Every id in a module (module, object, field, view, action, workflow, step, connection, variable, event, policy) is a uuid. Generate them with `devias id <count>`. Never invent dotted or readable ids.
> Run `devias plan` and read its output before `devias apply`. Apply only what the plan says.
> The OpenAPI document, including the routes of the modules in the reference setup, is at /reference/api/openapi.json.
> Devias is young and changes quickly. If a page and the source repository (github.com/devias-io/devias) disagree, the repository is right.

# Architecture

> The three parts of Devias and how a change travels through them. The studio is the React app, the server is an API with a data engine over Postgres, and modules plug into both. Every client uses the same API and the same permission check.

Devias has three parts: the **studio**, the **server** and **modules**. All clients, including the studio, scripts, workflows and agents, reach the data through the same server.

## Parts of Devias

| Part | What it is |
| - | - |
| Studio | The React app people use: tables, boards, record pages, workflows and the assistant. |
| Server | An HTTP API with a data engine behind it. It stores data in Postgres, checks permissions and announces every change. |
| Modules | Packages that plug into both sides. A module adds objects, views and actions to the server and screens to the studio. |

```text theme={"dark"}
studio  ──────►  API + data engine  ──────►  database
   ▲                      ▲
   └────────  modules  ───┘
```

## One way in

The studio, scripts, workflows and agents all call the same server. There is no side door: anything the studio can do, the API can do, and the same permission check applies to both. See [Access and permissions](https://docs.devias.io/concepts/access.md).

## Every change is an event

When a record changes, the server writes an event. Events keep open pages up to date, start workflows, and let other systems follow changes without polling. See [Change feed](https://docs.devias.io/reference/api/change-feed.md) and [SDK events](https://docs.devias.io/reference/sdk/events-and-notifications.md).

## The studio draws what the data describes

The studio has no built-in knowledge of a "deal" or a "person". It reads a description of the objects, fields, views and layouts in the workspace and draws whatever it finds. A field added in Settings and a field shipped by a module therefore look and behave identically.

## Related

* [Data model](https://docs.devias.io/concepts/data-model.md): objects, fields and records.
* [Modules](https://docs.devias.io/concepts/modules.md): how an area of the business is packaged.
* [Deploy](https://docs.devias.io/operate/deploy.md): run the server and the studio.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.