Databases Azure

Autobase for PostgreSQL on Ubuntu 24.04 on Azure User Guide

| Product: Autobase for PostgreSQL on Ubuntu 24.04 LTS on Azure

Overview

This guide covers the deployment and configuration of Autobase for PostgreSQL on Ubuntu 24.04 on Azure using cloudimg Azure Marketplace images.

Autobase (formerly postgresql_cluster) is an open source platform for running your own PostgreSQL as a managed service. From a single web console you deploy production-ready PostgreSQL clusters, either highly available with Patroni, etcd and an HAProxy load balancer, or a lightweight single node, and then operate them over their whole lifecycle: scaling, switchover and failover, minor and major version upgrades, configuration changes, automated backups with pgBackRest or WAL-G, and built-in monitoring. The console is the control plane; it drives an Ansible automation engine, while the database nodes themselves stay independent servers that you own, whether they run on a cloud provider or on your existing machines reached over SSH.

This image ships the Autobase Community Edition (CE) console — the fully open source (MIT) console UI, API and datastore, plus the Ansible automation engine — as a hardened Docker Compose stack fronted by nginx over TLS. The proprietary Enterprise Edition images are not included.

Security is designed in for a tool that holds the keys to your database fleet:

  • On first boot each instance mints its own console access token, its own console datastore password, its own secret-storage encryption key and a per-VM self-signed TLS certificate, all into files only root can read. No two deployments share crypto material, and the published example token is rejected before the console will start.

  • The image ships empty: no stored target servers, no SSH keys, no database credentials, no clusters. You point the console at your own fleet after launch.

  • The console UI is the only externally reachable service, behind nginx TLS on port 443. The console API, the console datastore and the bundled SQL studio are bound to an internal Docker network and are never published on the public NIC.

What is included:

  • Autobase Console (Community Edition) 2.10.0 — UI, API and PostgreSQL 16 + TimescaleDB datastore, all pinned by immutable @sha256 image digest

  • Autobase Ansible automation engine (vitabaks.autobase) for cluster deployment and lifecycle operations

  • dbdesk-studio browser SQL client, reachable only through the console

  • host nginx TLS front door on port 443 (port 80 redirects to HTTPS)

  • autobase-firstboot.service — mints all per-VM secrets and the TLS certificate before the console starts

  • a dedicated 64 GiB data disk mounted at /srv/autobase holding the compose stack, secrets and TLS material

  • Ubuntu 24.04 LTS base with the latest security patches applied at build time and unattended security upgrades enabled

  • Azure Linux Agent for seamless cloud integration and SSH key injection

  • 24/7 cloudimg support with a guaranteed 24 hour response SLA

Prerequisites

  • An active Azure subscription

  • A subscription to the Autobase for PostgreSQL on Ubuntu 24.04 listing on Azure Marketplace

  • An SSH public key for VM authentication

  • A virtual network and subnet in the target region

Recommended virtual machine size: Standard_B2ms (2 vCPU, 8 GB RAM). The console with TimescaleDB monitoring for a fleet of managed clusters is comfortable at 8 GB; the extra memory over a 4 GB size gives the monitoring datastore headroom as the number of managed clusters grows. The PostgreSQL clusters you deploy run on their own target servers (which you size for your workload), not on the console VM.

Step 1: Deploy from the Azure Portal

Navigate to Marketplace in the Azure Portal, search for Autobase, select the cloudimg publisher entry, and click Create.

On the Networking tab attach a network security group that allows inbound TCP 22 from your management IP range and TCP 443 from the trusted networks that will reach the console. The console deploys clusters over SSH, so the VM must be able to reach your target database servers on TCP 22 (outbound).

Click Review + create, wait for validation, then Create. Deployment takes around two minutes; the console then needs a further minute or two on first boot to mint its secrets and bring the stack up.

Step 2: Deploy from the Azure CLI

RG="autobase-prod"
LOCATION="eastus"
az group create --name "$RG" --location "$LOCATION"

az vm create \
  --resource-group "$RG" \
  --name autobase-console \
  --image <publisher>:<offer>:<sku>:latest \
  --size Standard_B2ms \
  --admin-username azureuser \
  --generate-ssh-keys \
  --public-ip-sku Standard

# Open SSH (administration) and HTTPS (the console):
az vm open-port --resource-group "$RG" --name autobase-console --port 22 --priority 1001
az vm open-port --resource-group "$RG" --name autobase-console --port 443 --priority 1002

Step 3: Connect via SSH

ssh azureuser@<vm-ip>

Step 4: Verify the Console Stack

The console runs as a Docker Compose stack managed by autobase.service. Confirm the containers are up and the API answers:

sudo docker ps --format '{{.Names}}\t{{.Status}}'

sudo test -f /var/lib/cloudimg/autobase-firstboot.done && echo "first boot: complete"

The four containers (autobase-console-ui, autobase-console-api, autobase-console-db, dbdesk-studio) should all report Up, with the API and datastore healthy.

Autobase console stack healthy and first boot complete

Step 5: Retrieve the Console Access Token

On first boot the console mints a per-VM access token, console datastore password and secret-storage encryption key. The token is what you log in to the console with. It is written, along with the console URL, to a root-only credentials file:

sudo cat /root/autobase-credentials.txt

The file is mode 0600 root:root and contains autobase.url, autobase.auth.token and autobase.console.db.password. Keep the access token secret — anyone holding it has full control of the console.

Per-VM access token, console database password and encryption key generated on first boot

Step 6: First Login

Browse to https://<vm-ip>/ (the console is served over TLS; port 80 redirects to HTTPS). The image ships a per-VM self-signed certificate, so your browser will warn on first visit — see Step 11 to install your own certificate for production. Paste the access token from Step 5 into the Token field and click Login.

Autobase Community Edition token sign-in page over TLS on a freshly deployed cloudimg VM

The token is held in your browser and sent as a bearer token on every API call, so it never crosses plain HTTP. You can confirm the API rejects unauthenticated calls and reports the running version:

curl -sk -o /dev/null -w '%{http_code}\n' https://127.0.0.1/api/v1/environments

curl -sk -H "Authorization: Bearer <AUTOBASE_AUTH_TOKEN>" https://127.0.0.1/api/v1/version

The first call returns 401 (auth enforced); the second returns the console version.

Step 7: The Clusters View

After login the console opens on the Clusters view. A freshly launched image ships with no clusters — you add your own. The screenshot below shows the console after a cluster has been deployed, reporting it healthy.

Autobase console Clusters view showing a managed PostgreSQL cluster reporting healthy

Step 8: Deploy a PostgreSQL Cluster

Click Create cluster. Autobase can deploy onto a cloud provider (AWS, GCP, Azure, DigitalOcean, Hetzner) by creating the servers for you, or onto existing servers you already run — including a single node — reached over SSH. For the existing-servers path you register a secret holding an SSH private key for a sudo-capable user on the targets, choose the topology (a highly available cluster with Patroni, etcd and HAProxy, or a lightweight single node), pick the PostgreSQL major version, and start the deployment. The console drives its Ansible engine to install and configure PostgreSQL, Patroni, etcd, PgBouncer and the rest.

Once the deployment finishes, the cluster overview shows the running leader, its connection details and the cluster metadata:

Autobase cluster overview showing the running PostgreSQL leader, connection info and cluster metadata

You then connect to the deployed database with any PostgreSQL client and use it normally:

psql -h <vm-ip> -p 6432 -U postgres -tAc "SELECT version();"

Console-deployed single-node PostgreSQL cluster reporting healthy, with a live query round-trip

Step 9: Track Operations

Every deployment and lifecycle action runs as an operation you can follow in the console, with the full Ansible log available for each one.

Autobase Operations view showing the deployment operation completed successfully

Step 10: Security Posture

The image is secure by default. The console UI is the only service reachable on the public NIC, over TLS; the console API, its datastore and the dbdesk SQL studio are bound to an internal Docker network. Port 80 redirects to HTTPS, first boot is enabled, and the OS ships fully patched with nothing held back from security updates.

sudo systemctl is-enabled autobase-firstboot.service autobase.service

curl -s -o /dev/null -w ':80 -> HTTP %{http_code}\n' http://127.0.0.1/

Secure by default: TLS front door only, console internals not on the public NIC

Step 11: Install Your Own TLS Certificate (Production)

The image ships a per-VM self-signed certificate so the console is available over TLS immediately. For production, replace it with a certificate for your own hostname. Point DNS at the VM, then install a certificate — for example with a companion reverse proxy, or by replacing the certificate and key the console nginx front uses:

sudo ls -l /srv/autobase/tls/

Replace autobase.crt and autobase.key with your own certificate and private key (keep the key mode 0600), then reload nginx:

sudo nginx -t && sudo systemctl reload nginx

Step 12: Managing the Console

sudo systemctl status autobase.service --no-pager

Stop or start the whole console stack through its systemd unit with sudo systemctl stop autobase.service and sudo systemctl start autobase.service.

The compose project, per-VM secrets and TLS material live on the dedicated data disk at /srv/autobase, so they persist across reboots and are independent of the OS disk.

Step 13: Troubleshooting

  • The console does not answer on 443. Check first boot completed (sudo systemctl status autobase-firstboot.service) and the stack is up (sudo docker ps). The console will not start until the per-VM secrets exist — a start-time guard refuses to run with an absent, example or too-short token.

  • Browser certificate warning. Expected on first visit with the shipped self-signed certificate; install your own certificate (Step 11).

  • A deployment fails. Open the operation in the console and read its Ansible log; the most common cause is the console being unable to reach a target server over SSH (check the target's security group and that the registered key's user has passwordless sudo).

Step 14: Support and Licensing

Autobase is distributed under the MIT License. The Community Edition console UI, API, datastore image and the Ansible automation engine shipped in this image are all open source; the proprietary Enterprise Edition is a separate set of images and is not included.

TimescaleDB notice (Timescale License, TSL). The console's internal monitoring datastore bundles TimescaleDB, which is distributed under the Timescale License (TSL) — a source-available licence, not open source. TimescaleDB is used here solely as the console's internal metrics store; you never manage or expose TimescaleDB yourself, and the clusters you deploy run vanilla PostgreSQL. The full TSL text is available at https://github.com/timescale/timescaledb/blob/main/tsl/LICENSE-TIMESCALE. Your use of the bundled TimescaleDB is subject to that licence.

The PostgreSQL clusters Autobase deploys install components onto your own target servers at deploy time (PostgreSQL under the PostgreSQL License, Patroni under MIT, etcd under Apache-2.0, HAProxy under GPL-2.0, PgBouncer under ISC, pgBackRest and WAL-G under MIT); none of these are baked into this image.

Deploy on Azure

cloudimg publishes Autobase for PostgreSQL as a hardened, ready-to-run image on the Azure Marketplace, patched and secured with per-VM secret generation and an empty-by-default posture.

Need Help?

cloudimg provides 24/7 support with a guaranteed 24 hour response SLA for all marketplace images. Contact support through the cloudimg website.