Multiple installations

Isolate jobs, policies, duties, schedules, workers, migrations, and wakeups.

An installation boundary includes jobs, policy state, singleton duties, schedules, workers, operations, migration history, and wakeups. Configuring only a different job table is not isolation. Headgate applies one backend-native boundary to every durable object.

PostgreSQL schemas

Create and migrate each schema explicitly:

psql "$DATABASE_URL" <<'SQL'
CREATE SCHEMA "billing-jobs";
CREATE SCHEMA "email-jobs";
SQL

hg-migrate --database-url "$DATABASE_URL" --schema billing-jobs up
hg-migrate --database-url "$DATABASE_URL" --schema email-jobs up

Construct each store with the matching schema:

Rust

let billing = PgStore::connect_in_schema(
    &conninfo,
    16,
    "billing-jobs",
)?;

The same caller-owned pool may serve stores for different schemas. Every relation is quoted and qualified at the query boundary; Headgate does not change or trust search_path. A schema-specific hashed LISTEN channel prevents one installation’s enqueue from waking another.

Run every migration operation with --schema, including validate, adopt, and down.

MySQL databases

MySQL’s boundary is the selected database. Give each installation a separate database:

mysql://headgate:secret@db:3306/billing_jobs
mysql://headgate:secret@db:3306/email_jobs

Migration locks include DATABASE(), validation filters that database, and all runtime SQL resolves inside the connection’s selected database. Headgate deliberately has no table-prefix mode that could leave duties or migration history ambiguous.

Redis prefixes

Redis uses one explicit key prefix as the complete boundary:

Rust

let billing = RedisStore::connect(&url, "billing-jobs").await?;

Use a unique, stable production prefix. Never use FLUSHDB for cleanup; test helpers scan and remove only keys owned by their generated prefix.

Security boundary

Separate schemas, databases, or prefixes prevent accidental queue-state collision. They are not a hostile-tenant security boundary when the same credential can read all installations. Use distinct least-privilege credentials when cross-installation reads must remain impossible after an application compromise.

Schema migrations

Apply and validate each installation through the same backend boundary.