← All posts

Engineering

Multi-tenant by design: orgs and hosts

How one console runs many sites with roles, billing, and isolation baked in.

The Aglyn Team · Aug 2026
Multi-tenant by design: orgs and hosts

One login should be enough to run everything you publish — a portfolio, three client sites, and a storefront — without those properties ever bleeding into each other. That's the tension multi-tenancy resolves, and in Aglyn it isn't a feature we bolted on. It's the shape of the platform.

Orgs own everything

An organization is the unit of ownership: members, roles, billing, and shared assets live at the org level. Your team joins once, gets a role, and sees exactly the sites that role allows. Agencies run each client in its own org or group sites under one — both work.

Hosts are the unit of isolation

Each site — we call the runtime a host — has its own screens, content collections, media library, forms, and domain. Nothing leaks across hosts by default: a collaborator scoped to one site can't wander into another, and one site's data model never collides with its neighbor's.

Shared where it helps

Isolation without sharing would mean duplicating everything, so the org layer carries what should be common: org-level media shared with chosen sites, members who span projects, one bill for all of it.

Why it's an architecture, not a setting

Because tenancy is enforced in the data model and security rules — not in UI filters — the guarantees hold everywhere: in the console, in the editor, on the published sites, and through the API. That's what "multi-tenant by design" means: the walls were poured with the foundation.

The Aglyn Team
Share this article
The Aglyn Team

We're building the open web platform. Follow along as we ship — and tell us what you need.

Start building on Aglyn.

Free to start — design your first page and publish in minutes.