A small cloud should have a small, understandable trust model. This page says what is isolated, which credentials exist and where the current boundaries are.

One host per org. An org's apps run in its own Docker environment rather than in a shared application runtime with other orgs.

Inside the host:

• each app instance runs as its own project;
• services receive only the configuration meant for that instance;
• persistent volumes belong to that project;
• app routes are generated from the host's own state;
• the host agent connects outward to the control plane.

So the application boundary between orgs is the host boundary.

Private requests are authenticated before they reach the app. A private app sends a visitor without a session to the Hub control plane.

Hub checks the person's org membership and returns a short-lived token bound to the app hostname. The org host validates that token and sets an app-specific session cookie.

The app receives the identity headers, and Hub's own cookie is removed before the request is proxied. Public apps get no Hub identity headers.

Web and CLI sessions are separate.

• Web sessions use secure, HTTP-only cookies.
• CLI sessions use bearer credentials stored in the user's Hub configuration directory.
• API writes take the bearer session, never a cross-site cookie.
• Web forms carry CSRF protection.

Values stay out of normal responses and logs. Hub encrypts environment values at rest. The CLI and the dashboard list names, never values.

Values reach the instance during a deploy or a configuration change, and nowhere else.

One limit to know: build-time values become Docker build arguments, and a Dockerfile can expose build arguments in image history or build output. Keep secrets in runtime variables.

Repository access is short-lived and scoped. Hub uses a GitHub App rather than a person's repository password or personal access token.

For a deploy, Hub mints a short-lived installation token for that one repository, fetches the requested commit and drops the token.

The fix agent never receives that token. The control plane applies an approved patch and opens the pull request.

The model proposes. A person decides. For eligible failed GitHub deploys, Hub runs an agent in a temporary sandbox on the org's host.

The sandbox has:

• no application environment values;
• no GitHub token;
• no host token;
• no Docker socket;
• no bind mount to the host filesystem;
• resource and time limits;
• access only to the source of one attempt;
• a restricted command interface.

Hub checks the resulting patch before opening a pull request. It does not merge the change.

Hosts dial out. The org host opens its own connection to the control plane and needs no public management port beyond the app traffic on HTTP and HTTPS.

Control, deploy, terminal and status messages travel over that authenticated connection.

Each org gets a wildcard certificate covering its root and its apps. The private key is made on the org's host and stays there.

Coming next: custom domains.

Product permissions are explicit. Hub has viewer, member, admin and owner roles for control-plane actions.

Every route names the lowest role it takes, and an org has exactly one owner. Opening a private app takes org membership.

What Hub is not claiming yet. Hub is early infrastructure for internal tools, demos, automations, dashboards and small operational apps.

It does not provide:

• multi-region high availability;
• horizontal autoscaling;
• managed database replication;
• automated volume backup and restore;
• a formal compliance certification;
• full workload isolation from the org's own host administrator;
• a packaged self-hosted edition with a supported upgrade channel.

Hub reduces the infrastructure and authentication each small app has to own. The app still has to secure its own business logic, validate input, handle sensitive data with care and keep external backups of anything critical.

Need to review the model for your environment?