Architecture
Runtime services
The six long-running services and the data stores Flexday AI runs on, what each one does, and how it scales.
- Technical
Last reviewed
Flexday AI runs as six long-running services built from four container images, plus a one-off migrate task that runs before every release. Three services serve web pages, two answer API requests, and one runs every background job. They share PostgreSQL, Redis, object storage and a shared file system.
At a glance
- Six services, four images. Studio web, Admin Console and the apps server are three web images. The Studio API, the gateway and the worker are one image started three ways.
- The gateway, the worker and the web apps scale out. Add replicas behind the load balancer and the queue. The Studio API is built to run as several replicas too, and today's deployments run it as one.
- The gateway runs with less privilege. It connects to the database as a restricted identity that cannot read datasets directly.
- The worker is the only place jobs run. The API starts jobs and streams their progress, and never executes one itself.
The services
| Service | What it does | Scales |
|---|---|---|
| Studio web | The builder's web app. It holds no data of its own; every byte comes from the Studio API. | Stateless; add replicas |
| Admin Console | Flexday staff's console, on its own sign-in. It also holds no data of its own. | Stateless |
| Apps server | Serves each workspace's generated apps from object storage and injects the runtime SDK into every page. | Stateless |
| Studio API | The REST API for Studio and the Admin Console, plus live progress streams. Starts background jobs. | Built to scale out; deployed as one replica today |
| Gateway | Runs every generated app's and outside system's requests: queries, Flows, Agents, files, sign-in completion, sign-out and Teams webhooks. | Horizontally |
| Worker | Runs every background job: Builder turns, Flow runs, document ingestion, Agent turns and scheduled sweeps. | Horizontally |
| Migrate | A one-off task that applies database changes before any service is updated. Only one copy can run at a time. | Runs once per release |
Why the gateway is separate
The gateway serves requests from the public internet on behalf of apps nobody at Flexday wrote by hand. So it runs as its own process on a least-privilege database identity. It can read the configuration it needs and run a saved query under a Fact Base role, but it cannot read a dataset directly or write platform records. The few writes it genuinely needs (for example recording an uploaded file) go through narrowly defined database functions.
Why the web apps hold no data
Studio, the Admin Console and generated apps all call the API from the browser. Their pages and the API are always on different origins, and none of them works out the API's address from the page it is on. That keeps a compromised page from borrowing another surface's session. See Addresses and domains.
The data stores
| Store | What it holds |
|---|---|
| PostgreSQL | The system of record: workspaces, Solutions, every resource definition, versions, the audit trail and usage records. One separate schema per Fact Base. Document text, the keyword index and (by default) vectors for search. |
| Redis | Durable job queues, live progress events, rate and send counters, and short-lived caches. |
| Object storage | Deployed app files and their versions, File Store files and every revision, Doc Base source documents and export bundles. |
| Shared file system | Only older copies of app Drafts and uploaded sample data, written before both moved to object storage and still read until they are migrated, plus temporary upload space. Amazon EFS on AWS, Azure Files on Azure. |
See Data architecture for how each store is partitioned by workspace.
Operating characteristics
- Health and readiness. Each service answers a health check. The API's readiness check also confirms that the database schema is current, and on a multi-workspace deployment with sign-in enforced it refuses to report ready if its database identity could bypass row-level security.
- Graceful shutdown. On a rolling deployment a service stops taking new requests, lets in-flight ones finish, and ends live progress streams with a final message so browsers reconnect cleanly.
- Releases are ordered. The migrate task runs first. Services then roll one at a time.
- Configuration reaches running apps quickly. Endpoint and Identity changes apply within about 30 seconds across every replica, and immediately in the process that made them.