Deploying Galleon takes the server itself and PostgreSQL.
The server is a single process, it accepts requests on port 8080
by default and can serve HTTPS itself once a certificate and a key are set
(TLS). PostgreSQL holds the metadata of the installation.
A reverse proxy is deployed in front of the server when needed
(Reverse proxy).
The artifacts themselves are stored as files in the storage directory on the server disk (see Storage and garbage collection).
To obtain the Galleon distribution, contact the vendor.
System requirements
Minimum server requirements:
- CPU and memory: 4 vCPU and 4 GB RAM.
- Disk: the server itself needs almost no disk space — the volume is determined by the stored artifacts (the storage directory) and the database.
- PostgreSQL version 16 or newer. With the default server settings, the database needs
max_connectionsof at least 110. - The database and the role named in the configuration are created in advance. Galleon connects to the database and runs migrations as that role, so the role needs rights to create tables and the
pg_stat_statementsextension.
First start
The minimal configuration is four blocks (the full parameter reference is in Configuration parameters):
database:
host: localhost
port: 5432
user: galleon
password_env: GALLEON_DATABASE_PASSWORD
dbname: galleon
storage:
default:
type: local
local:
root: /var/lib/galleon/data
security:
secret_key_file: /etc/galleon/secret-key.yaml
auth:
bootstrap_admin:
username: admin
password_env: GALLEON_BOOTSTRAP_ADMIN_PASSWORDTo start the server, follow these steps:
Save the configuration to a file, for example
/etc/galleon/config.yaml.Create the encryption key and store it in the key file (see Secrets and the encryption key for details):
openssl rand -base64 32# /etc/galleon/secret-key.yaml active: 1 keys: - id: 1 key: "<BASE64>"Set the passwords in the environment variables named in the configuration:
export GALLEON_DATABASE_PASSWORD='<database password>' export GALLEON_BOOTSTRAP_ADMIN_PASSWORD='<first administrator password>'Start the server:
galleon --config /etc/galleon/config.yaml
On the first start, Galleon creates the first administrator and the starter set of repositories.
Migrations at startup
By default, the server brings the database schema to the required version and continues serving — no separate step is needed. When the instance has several servers, one of them runs the migrations while the others wait their turn and start once the schema is ready.
The migrations can be moved into a separate run — to update the schema before rolling out a new version, for example. Two mutually exclusive flags do that:
--migrate-only— apply the migrations and exit without starting to serve;--skip-migrate— do not apply the migrations, but check that the schema is not older than the required one and start serving. If it is older, the server does not start.
If the database is still booting at startup, the server exits at once. To make the server wait for the database, set a waiting budget:
database:
migrate_wait: 5mThe waiting covers only the signs of “the database is not ready yet”: a refused connection, an unresolvable name, a connection timeout, a database server that is starting up or recovering, a missing database. Wrong credentials are not covered — the server exits at once.
The exit code separates a temporary cause from one that needs attention:
| Code | Meaning |
|---|---|
0 | The migrations are applied |
1 | The start failed: wrong credentials, an SQL failure. The cause needs looking into |
75 | The start was interrupted by an external cause: a stop signal or the exhausted database waiting budget. Starting the server again is enough |
The migrations can be interrupted at any moment. The unfinished step is rolled back whole, and the next start resumes from it.
Verification
Make sure the server responds:
curl http://localhost:8080/healthz
curl http://localhost:8080/readyzhealthz confirms the process is alive;
readyz — that the database is reachable.
See Monitoring for details.