Self-hosted vs platform
Every rule that differs between self-hosted mode and platform mode, from one policy table in the code.
CHELABASE_MODE is self-hosted (the default: an instance you install and operate) or platform (the hosted cloud, not built yet). Every decision that depends on the mode lives in one place in the code, ModePolicy, so nothing else compares the mode. Platform mode fails closed: where a feature isn't designed for it yet, the answer is refused (403 not_available_in_platform_mode) rather than falling back to the self-hosted behaviour.
In practice
- Sign-up. Self-hosted has no self-sign-up unless a tenant admin turns on open sign-up. People who sign up then wait as pending members for an admin to approve them. Platform mode refuses self-sign-up until it is designed. See Members and invites.
- Instance settings (
/v1/instance/settings, open sign-up) are for the active tenant admin when self-hosted; in platform mode they are for members of the operator tenant (CHELABASE_OPERATOR_TENANT_ID), and nobody passes while it is unset. The open sign-up switch exists only when self-hosted. - How members are made. Only explicitly, in both modes: by an accepted invite, an approved sign-up, or (self-hosted) the claim of a fresh install, whose first sign-up needs the setup code that
init-secretsprinted (see Install; claim before exposing Studio; the loser of a simultaneous race is admitted as pending). A signed-in account with no member row is refused. - Safety defaults (email verification, password strength, owner superuser, pre-hashed passwords, the CA file on reveal) are relaxed for local use in self-hosted mode and strict in platform mode.
CHELABASE_REQUIRE_EMAIL_VERIFICATIONoverrides email verification in either mode. Secure cookies follow the public scheme in both modes (Secure withhttps), and platform mode requireshttps.
Correctness and safety checks are the same in both modes: the access rules in Access per route apply identically.
Every rule
This table is generated from ModePolicy and checked by a test (just check).
| Rule | What it decides | Self-hosted | Platform |
|---|---|---|---|
instance_admin | Who may use instance-level routes. | active tenant admin | member of the operator tenant |
sign_up | Whether a visitor may create their own account. | gated by the tenant | refused |
open_signup_switchable | Whether the tenant may switch open sign-up on. | true | false |
email_verification_default | Whether sign-ups must verify their email by default. | false | true |
owner_superuser_allowed | Whether a database's owner role may be a superuser. | true | false |
password_strength_forced | Whether role passwords must pass the strength check. | false | true |
prehashed_passwords_allowed | Whether role passwords may be supplied pre-hashed. | true | false |
ca_file_on_reveal | Whether revealing connection details includes the dev CA path. | true | false |
default_internal_token_allowed | Whether the services may start with the development internal bearer (a platform instance refuses to start with it). | true | false |