Isolated Deployment

What It Is

In an isolated deployment every tenant runs on its own, with nothing shared with other tenants. A tenant is a pair of environments:

  • production, where the organization works;
  • development, where the implementation is built and tried out before it reaches production.

Each environment has its own application container, database, cache, private network and file volume. The Jetstack console provisions the pair, gives it its domains, keeps it up to date, backs it up and lets operators read its logs and query its database.

The same application image also runs self-hosted, on a customer's own machine, as the same production and development pair (see Self-Hosting).

Why It Matters

Isolation decides what one tenant can do to another, which is nothing:

  • a slow report or a heavy import in one tenant does not slow down any other;
  • a tenant's data, files and secrets live only in its own resources;
  • a release can reach one tenant's development environment first, then its production, then the next tenant;
  • a tenant can be stopped, retired, archived or destroyed without touching anyone else.

The development environment exists for the same reason. Configuration work, new automations and imports happen there, against the tenant's own copy of the platform, and reach production by promotion when they are ready.

How It Works

One Environment

An environment is one application container plus its own MariaDB database and Redis cache, on a private network only these three share. The container runs:

  • the web server and PHP application;
  • the scheduler, which runs scheduled automations every minute;
  • a sender, which delivers queued e-mail, SMS and push notifications within seconds of being queued;
  • the live-update stream used by open browser tabs;
  • the AI assistant's service, when the environment uses it.

Uploaded files live on the environment's volume, or in an S3-compatible bucket when the environment is set up that way.

Production And Development

Both environments of a tenant run the same image. They differ in three ways:

  • A banner. Development shows a banner with a link to production, so nobody mistakes one for the other.
  • Outbound messages. Development never mails, texts or pushes to real people. It sends only to the override recipients set in the tenant, or to nobody (see the mail and SMS override settings in Application Settings).
  • Separate secrets. Each environment has its own keys, so a secret stored in one cannot be read in the other.

The First Administrator

When the console creates a tenant, the operator names its first administrator:

  • Who. An e-mail address and, optionally, a first and last name.
  • The password. Either the operator sets it, or one is generated for each environment and shown once on the tenant's page in the console.
  • Development. It gets the same administrator, another person, or none yet.

The administrator is a tenant administrator: they manage users and roles, set production's change policy, and may download the jetstack CLI. The operator can reset an environment's administrator later from the console. A self-hosted installation asks for the administrator's password while it installs (see Self-Hosting).

Identity And Domains

Every environment has a tenant ID and one or more domains:

  • Tenant ID. Fixed when the environment is created, usually its first domain. It never changes; it names the environment's data and its lineage in Promotion And Packages.
  • Primary domain. Where links, e-mails and sign-in point. It can be the provider's subdomain or the organization's own domain.
  • Aliases. Further domains that serve the same environment, such as a legacy domain kept so that old links keep working. An alias can instead permanently redirect visitors to the same page on the primary domain.
  • Entry domains. An alias can open one custom app instead: at / while the rest of the platform stays reachable, or exclusively, serving only that app at the root of the domain. A website or customer portal then has its own domain next to the back office. See Entry Domains.

Domains can change later. Changing the primary domain keeps the tenant ID, so nothing inside the tenant has to be updated.

Releases

A release is an immutable image version. Operators roll it out in rings: development environments first, then production environments one at a time, stopping at the first failure. Each step replaces the container without downtime:

  1. The new container starts and becomes healthy.
  2. The old one stops taking new requests.
  3. The old one finishes the requests it is handling.
  4. The old one stops.

Database changes are additive, so going back to the previous version is safe.

Platform Migrations

A release can bring migrations: changes to the data that the new version needs, such as filling a new column from existing values. Each environment runs each migration once and records it in its own ledger. Every migration declares one of two kinds:

  • Blocking. It must finish before the new version serves anyone. The new container runs it while it starts, before it takes requests; the previous version goes on serving meanwhile.
    • These are kept short, seconds rather than minutes.
    • If one fails, or outlasts the start-up allowance, the new container never takes over. The previous version keeps serving and the operator sees why.
    • Finished work stays done, and the next attempt carries on where it stopped.
  • Background. It runs after the new version is live, in short slices from the scheduler. The new version works correctly while it is still running.
    • A failed background migration is retried after 1, 5, 30 and 120 minutes.
    • After that it waits for the operator.

Migrations only go forward; there is no undo. A release never removes what the previous version still uses, so going back to the previous version remains safe after its migrations have run.

Where to see the state of migrations:

  • Operators see it on the tenant's page in the console, for each environment.
  • Releases. An upgrade, or a rollout ring, stops when an environment reports a failed migration.
  • On the server: jetstack-admin migrate status inside the container.

Usage

Each environment counts once a day what its tenant uses: the database's size, files, records, users, apps, and the API calls of the day before. Tenant Admins see the counts on the Usage screen. The operator's console shows the latest count on each environment's card, from the usage of /_ops/status; images before the count report no usage, and a fresh environment reports null until its first count.

Backups And Archives

  • Scheduled backups. Every environment's database and file volume are backed up on a schedule, kept on the server and optionally copied to off-site S3 storage.
  • Final archive. Before a tenant is retired or destroyed, the console takes a final archive of each environment (database, files and configuration) and keeps it after the tenant is gone.

Sign-In With Google And Microsoft

Managed tenants sign in with Google and Microsoft through the provider's identity broker. It holds the OAuth clients for every tenant, so a tenant's domains never have to be registered with Google or Microsoft. The environment verifies a short-lived, signed confirmation from the broker for its own domain, then continues exactly as with its own sign-in:

  • registering;
  • logging in, including choosing between several accounts;
  • connecting an account to an existing user;
  • issuing an API key.

Self-hosted environments use their own OAuth clients instead.

How To Use It

Work In Development, Promote To Production

Build and test in the development environment, then move the result to production:

  • the configuration and every app together with promotion: jetstack promote --to prod, or "Promote to production" on development's History screen;
  • each app's release unchanged, so production runs exactly the release that was tested.

Data does not move between the two environments; configuration and code do.

Expect Development To Sleep

A development environment that serves no request for a while may be stopped to free the server's memory. When this is set up, operators start it again on request. Plan demos and long-running imports accordingly, or ask for the idle time to be extended.

Plan Domain Moves With The Operator

To move a tenant to the organization's own domain:

  1. Point the domain's DNS record at the server.
  2. Ask the operator to make it the primary domain, keeping the old one as an alias (serving or redirecting) so that existing links and bookmarks keep working.

Users stay signed in on the domain they are using; links in new e-mails use the new primary domain.

Give An App Its Own Domain

To put a website or portal on its own domain:

  1. Build it as a custom app and deploy it to production.
  2. Point the domain's DNS record at the server.
  3. Ask the operator to add the domain and assign it to the app, as opening it at / or as serving only the app.

Serving only the app needs a platform version that knows entry domains; the console refuses the setting until production runs one.

Example

A municipality moves from town.jetstack.app to portal.town.cz.

  1. The town adds an A record for portal.town.cz pointing at the server.
  2. The operator changes the production environment's domains:
    • primary portal.town.cz;
    • town.jetstack.app kept as a redirecting alias.
  3. The environment is redeployed without downtime. The development environment's link to production follows.

Old bookmarks land on the same page under the new domain, and the tenant's automations, files and synchronization history are untouched: its tenant ID is still town.jetstack.app.

Best Practices

  • Treat development as disposable data and durable configuration: import realistic samples there, never production personal data.
  • Keep override recipients set in development, so testing an automation that sends e-mail reaches your team.
  • Prefer a redirecting alias for an old domain once its users have moved, so search engines and bookmarks converge on one address.
  • Take a final archive before any change you might want to undo wholesale, such as a large data migration.
Previous← GroupsNextLegal Grounds And Purposes →