Solutions

Stackap for agencies

An agency can run its clients' apps on one Stackap server, with each client in its own organization whose projects, tokens and git keys the others cannot see or touch.

The situation

An agency usually carries a pile of small hosting accounts: one per client, each with its own bill, its own logins and its own way of being deployed. The cost is not only money. It is the time spent remembering where each client lives.

Stackap's answer is to put them on one server with walls between them, so that the agency runs one platform and each client sees only their own work.

What Stackap gives you here

• Organizations. Each client is its own organization with an owner token, and every project, token and git key belongs to exactly one.
• Per-organization git keys that can reach only that organization's repositories.
• A single wall in the code that filters everything by the caller's organization, with a test that fails the build if any query skips it, and an attack suite of 43 cross-organization attempts that are all refused.
• Identical responses for a resource in another organization and one that does not exist, so a client cannot learn what another client has called a project.
• One backup system and one monitor for every client's app.

How it looks in practice

The operator, which is the agency, creates an organization for a client through the API and gives them an owner token, shown once. The client can then deploy their own projects, or the agency can do it for them. The agency keeps a platform-level view of health across all of them.

The same design runs the founder's own multi-tenant CRM, which serves roughly a hundred businesses from one codebase. Stackap copies that approach rather than inventing one.

Early-access fit

Early access is a less natural fit if any client could be hostile. Tenant code is not sandboxed: each organization's apps run on the same machine, in containers with limits, but not inside a hardened sandbox. Organizations are therefore created only by the operator, for parties that are trusted.

Early access is a less natural fit if clients expect to create organizations themselves. Organizations are created by the operator, through the dashboard, the API or the command line.

Early-access scope

• Tenant code is unsandboxed, so this suits trusted clients only.
• Organizations are created by the operator; clients do not create their own.
• A second, database-level lock (row-level security) beneath the application wall is planned, not built.
• No independent security review has been done, and there are no compliance certifications.

Questions

Last updated 2026-10-03.