BettikDocsSign in

Reference · on the box · network

On the box: names, databases and cookies

For a session on a box: what the network calls things, how to reach an environment's database, and how to write cookies for an environment. Your environment and its neighbours is the same ground for the person.

Names on the network

Each environment has its own network. Its services reach each other by name on it, and the workbench is on every one of them, so from the workbench every container of every environment is reachable by <environment>-<service> and the port the service itself listens on: dev-web:3000, dev2-db:5432. Nothing here needs a port number. The workbench is workbench to an environment, so something you run there on 0.0.0.0 is reachable from any environment as workbench:<port>.

An environment cannot reach another environment by name. dev does not see dev2-db. Environment to environment goes through the other environment's public address, its URL as environment_status gives it, like any outside caller: it gets only what that environment opens, through open paths in its bettik.json or by being shared public, and it checks its own token. There is no private link between environments, on purpose.

Lookups from every environment and from the workbench go through the box's own resolver, which counts which names each one asks for; admin shows it as where each environment talks to. Nothing is blocked.

An environment's database

An environment's database answers at <environment>-db:5432 from the workbench. The credentials are in the environment's .env, which is the only place they are:

set -a; . ~/environments/<environment>/.env; set +a
psql "$DATABASE_URL"

There is no shell inside an environment's containers and no need for one: the code is in the workbench, the database is on the network, and the containers' output is environment_logs.

Cookies in an environment

Every environment shares one domain, so to a browser they are one site: another environment can plant a cookie on this one, and send it requests carrying its SameSite cookies. In code you write for an environment, name login and session cookies __Host-… (Secure, Path=/, no Domain), and check Origin or use a CSRF token for anything that changes state, rather than relying on SameSite alone. Sharing a cookie between environments on purpose is the person's call.