Deploying ApertureDB
You can deploy ApertureDB on your own host or Kubernetes cluster using three packages published on Docker Hub. Choose the package that matches how you manage your infrastructure, then follow its installation guide.
Method | Docker Hub package | Use it for |
|---|---|---|
| Running on one host, with local or cloud storage. | |
| Managing a distributed Kubernetes deployment with Helm. | |
| Managing a distributed Kubernetes deployment as code with OpenTofu. |
The Compose layouts, Helm chart, and OpenTofu module are OCI artifacts consumed by their respective tools. Docker Compose loads its configuration directly from the registry. Each package deploys the database and supporting services, including the Lenz gateway and Web UI.
Choosing a version
Replace <package-version> in the guides with a published release tag from the corresponding Docker Hub repository:
Compose tags include the layout name: <package-version>-single-node, <package-version>-distributed-local, or <package-version>-distributed-cloud. A published release supplies matching ApertureData image defaults. Keep those defaults unless you need a compatible override; each guide identifies the available settings.
If your supplied images require registry access, use your authorized Docker Hub account. Authenticate the package download with docker login for Compose or helm registry login registry-1.docker.io for Helm. OpenTofu uses its OCI registry authentication configuration. Kubernetes also needs an image pull secret for any private workload images; authenticating a local package download does not configure the cluster.
Storage and credentials
Compose offers a single-node layout with local storage, a distributed layout with local storage, and a distributed layout with object storage. All three run on one Docker host; running multiple database containers on that host does not protect against failure of the host itself.
The Kubernetes guides deploy distributed ApertureDB with an existing object storage bucket. They deploy resources into an existing cluster and do not provision the cluster or bucket. Use a dedicated bucket for each independent database deployment.
For AWS S3, select storage type s3 and supply credential JSON of this form:
{
"access_key": "<access-key>",
"secret_access_key": "<secret-access-key>",
"region": "us-west-2"
}
The credentials must permit the database to list the bucket and read, write, and delete its objects, including multipart uploads. Have your storage administrator provision the bucket and suitable permissions before starting. S3-compatible storage may require additional endpoint configuration.
For Google Cloud Storage, select gs and supply the service account’s JSON credentials, with permission to list, read, create, and delete objects in the bucket. Each guide shows where to supply the bucket name and credential JSON.
Set a strong database master key before starting. The initial database login is admin with the master key as its password. Monitoring uses a separate bearer password; Grafana also has its own administrator login. Keep credentials out of source control.