Setting up a client installation

Each client gets its own copy of the application. Nothing is shared between clients: not the database, not the files, not the network.

1. Prepare the folder

A folder is created per client with the same base content: the compose.yaml, the variables template and the code. What changes is the .env file and, later, the company data in Settings › Company.

The variable that tells everything apart is CLIENTE. With it, the containers are called <cliente>-api and <cliente>-db, the volumes <cliente>-pgdata and <cliente>-archivos, and the network <cliente>-net. Without it, everything would be called organtia and two clients would collide.

2. The variables you have to touch

Variable	What it is for	Example
CLIENTE	Short client name: it names the containers, volumes and network	acme
RED_SUBNET	That installation’s own subnet (two installations cannot share it)	10.99.43.0/24
API_PORT	Local port where the api listens (loopback only)	18012
DB_PORT_HOST	Local PostgreSQL port for the tests	54330
DB_NAME, POSTGRES_USER, POSTGRES_PASSWORD	That client’s database	—
ACCESO_CLAVE	Initial password for the office door	—
ACCESO_DIAS	Days the session lasts before asking for the password again	7
TZ	Time zone of the installation and its cron jobs	Europe/Madrid
MARCA, CLIENTE	Product name and short installation name	Acme
EMPRESA, CEO_NOMBRE, LEGAL	Seed for the company data: first time only

Caution

POSTGRES_PASSWORD is mandatory: if it is missing, startup refuses to bring up the database instead of creating it without a password.

3. Bring it up

The image is built once and started. The same image serves every client: what changes is the configuration.

On the first startup the tables are created, the migrations are applied and the owner user is created with the password from ACCESO_CLAVE.

4. The subdomain

Each client has its own address, of the form nombre_cliente.organtia.com. In the proxy you add a block that:

1. Listens on that name.
2. Requests the HTTPS certificate automatically.
3. Forwards to that installation’s api, on its local port.

Nothing else is exposed: the database and the files have no door to the internet.

5. Check that it is right

• Open the address and sign in with the owner user.
• Check that the office has the staff seated.
• Request a small assignment and see it delivered.
• Look at the log: the sign-in entry and the assignment should both be there.

Updating an installation

The api image is rebuilt and started again. Pending migrations apply on their own. Tests are run beforehand, in a separate container, against a disposable database.

What the application does not do

• It does not make backups: the server’s backup system does, daily, over the volumes. The application keeps no backups of its own.
• It does not update itself: updates are decided and run by hand.