Skip to main content
This page is for operators who run the Airhouse server themselves, with access granted by Oxygen (see Getting access and Installation). If someone else runs Airhouse for you, you only need your connection parameters.

How configuration is loaded

Airhouse reads settings in this order, with later sources winning:
  1. Built-in defaults.
  2. A TOML file, if the AIRHOUSE_CONFIG environment variable points to one.
  3. Environment variables.
Every section in the file is optional. Omitting a section keeps its defaults. Use environment variables for secrets such as passwords, keys, and tokens.
Boolean environment variables accept true/false, yes/no, on/off, and 1/0.

Server

Authentication

Change the default password before exposing the server. If you configure neither static users nor the control plane, anyone with the default password connects as admin. See Users, roles, and security.

TLS

Catalog

The Postgres database that holds the DuckLake catalog when the control plane isn’t configured. With the control plane, each database gets its own catalog automatically.
Without the control plane, Airhouse serves a single database named airhouse. Set AIRHOUSE_DEFAULT_TENANT to use a different name. Clients connect with that name as the Postgres database.

Object storage

Where Parquet files are written. Any S3-compatible store works, including AWS S3 and MinIO.

Control plane

The control plane enables the Admin API: databases, users, and service accounts stored in a registry database. All three of database_url, admin_token, and catalog_admin_url are required to enable it.

Query limits

Result cache

Airhouse can cache query results and share one execution between identical queries that arrive at the same time.

Extensions

Every extension you add to the allowlist expands what SQL users can do on the server. Treat changes to it as a security decision.

Logging