Autobase for PostgreSQL: a self-hosted DBaaS built on Ansible

The problem Autobase targets: PostgreSQL HA without a DBA on staff

Running PostgreSQL in production is easy until the second server appears. Then you need streaming replication, a failover mechanism, backups that restore, and an upgrade path that does not end in data loss. Managed cloud services solve this by taking the servers away from you. Autobase takes the opposite route: it brings the managed experience into infrastructure you already own. The README calls it an "Internal Database Platform for PostgreSQL, bringing the managed database experience of DBaaS into your own infrastructure", and lists deployment, failover, backups, restore, upgrades and scaling as the automated operations.

The audience is explicit in the README: teams "without specialized expertise" in database operations. That is a narrower claim than it sounds. Autobase removes the need to hand-write replication and failover logic, but it does not remove the need to run Linux hosts, manage SSH access, or understand what a PostgreSQL cluster is. The topics list on the repository (patroni, auto-failover, cluster, high-availibility, self-hosted) tells you the underlying model: this is a control layer over a Patroni-managed PostgreSQL cluster, not a new database engine. If you have never operated Patroni, Autobase is a way to avoid learning its configuration format, not a way to avoid learning what it does.

Architecture: an Ansible collection with three front ends

The repository layout is the clearest statement of how Autobase is built. Two directories matter: automation/ holds the Ansible collection, and console/ holds the UI. The README describes three ways to deploy a cluster, and they are not three separate implementations: the console, the Ansible collection and the GitOps workflow are three entry points onto the same automation layer. The README itself says the Ansible Collection is "the automation layer for those who prefer Ansible playbooks instead of the database platform".

That ordering matters for evaluation. If the console is unavailable, or if you want cluster changes to live in version control, the underlying playbooks are still there and still usable. The GitOps path stores cluster configuration in Git and applies changes through CI/CD pipelines, which means the desired state of a cluster is a reviewable file rather than a sequence of clicks. The Makefile at the repository root bootstraps the collection with a Python virtualenv; it reads a Python version from .config/python_version.config and pulls in additional make targets from .config/make. There is a separate bootstrap-dev target that adds development dependencies on top of the standard bootstrap. This is a Python and Ansible project at the tooling level, even though the repository's primary language is listed as TypeScript (the console).

Installing Autobase and creating a first cluster

The README points to https://autobase.tech/docs for full documentation and does not inline installation commands. What the repository does give you is the bootstrap path through the root Makefile, whose help text prints the intended sequence: run make, then make bootstrap, then a target. The Makefile sets a Python launcher from .config/python_version.config and includes extra targets from .config/make, so the collection's own targets appear alongside the bootstrap ones.

make
make bootstrap
make <target>

The first invocation prints the help header rather than doing work, because the default goal is help. The second creates the Python environment the Ansible collection needs. After that, the available targets are the ones defined in .config/make. If you plan to modify the collection itself, the Makefile offers a development variant:

make bootstrap-dev

That runs bootstrap first and then installs development dependencies, so it is a superset of the plain path. The Makefile also defines reinitialization and reinitialization-dev targets that clean and re-bootstrap, which is the documented way back to a known state.

For the UI route, the README splits the console into two editions. The Community Edition is described as a free licence for individual developers and hobby projects, with lightweight cluster deployment. The Enterprise Edition is a commercial licence for production environments, with extended cluster management features and support. The README does not give console installation commands; those live in the console/README.md and on the documentation site. For the GitOps route, the README links to a documentation page rather than providing a manifest to copy. In all three cases the first real use is the same: define the hosts, define the cluster, and let the automation layer create the primary and its replicas. What you should see afterwards is a running cluster, and the repository's daily scheduled workflows are the project's own check that this works on each supported distribution.

What the compatibility matrix commits to, and what it does not

Autobase supports Red Hat and Debian-based distributions, and the README lists them precisely: Debian 11, 12 and 13; Ubuntu 22.04, 24.04 and 26.04; CentOS Stream 9 and 10; Oracle Linux 8, 9 and 10; Rocky Linux 8, 9 and 10; AlmaLinux 8, 9 and 10. Both x86_64 and aarch64 are listed. On PostgreSQL, the README claims all supported versions and then names the ones it says are tested and work fine: 10 through 18.

The more interesting part is the table of daily automated cluster deployment tests. Each distribution has a link to a scheduled GitHub Actions workflow, and the README presents that table as the result of daily testing. This is a genuine operational signal, because it means the supported distribution list is not a marketing claim but a list of targets someone is exercising. It is also a snapshot: a green badge in the README reflects the latest scheduled run, not a guarantee about your specific hardware, network layout, or storage configuration. Nothing in the README describes testing on Windows or macOS as server targets, and nothing describes a container-based deployment path. If your fleet is outside the listed distributions, Autobase is not claiming to support you.

Where Autobase is the wrong choice

The most concrete limitation is that the README does not document rollback. It lists upgrades among the automated operations, but there is no described procedure for reverting a cluster change that turns out badly, and no described procedure for recovering the control plane itself if the automation layer is what broke. For a platform whose selling point is reducing operational risk, that is a gap worth naming. The Makefile's reinitialization target cleans and re-bootstraps the tooling, which is a development convenience, not a production rollback story.

Second, the licence split is a real constraint, not a formality. The Community Edition is described as free for individual developers and hobby projects, with lightweight cluster deployment. Extended cluster management features and support sit behind the Enterprise Edition. If you need the extended features, you are evaluating a commercial product with an open-source automation layer underneath, and the README's statement that the project will remain open-source does not by itself tell you which features stay in the free tier.

Third, this is infrastructure software with infrastructure prerequisites. It targets dedicated Linux servers, and the automation is Ansible, so you need Python, SSH reachability and a host inventory. If you want a database you never think about, a managed cloud service is cheaper than the time you will spend on hosts. Autobase is for people who have decided the servers stay theirs.

Autobase compared with running Patroni yourself

The honest alternative is not another DBaaS product. It is assembling the same stack by hand: Patroni for the cluster and failover, plus your own backup tooling and your own upgrade runbook. The repository's own topic list names patroni, so the project is not hiding what sits underneath. The difference is in what you write. With a hand-built Patroni setup, you own the configuration templates, the bootstrap ordering, the backup schedule and the upgrade procedure, and you debug them when a distribution update changes a package name. With Autobase, the Ansible collection owns those pieces, and the distribution-specific work is the project's problem as long as your distribution is on the tested list.

That trade has a cost in the other direction. A hand-built stack is transparent: every file is one you wrote, and any behaviour can be traced to a line you can edit. Autobase inserts a layer between you and Patroni, and when something behaves unexpectedly you are debugging the collection's playbooks rather than your own. The GitOps path softens this, because cluster configuration becomes a file in a repository you control, but the automation that consumes that file is still the project's code. Choose Autobase if you want the cluster operations maintained for you and you are willing to accept the layer. Choose hand-built Patroni if you need to understand every moving part, or if your environment is unusual enough that a maintained distribution list is a poor fit.

Licence, maintenance and the cost of upgrades

The repository is MIT licensed, and the LICENSE file sits at the top level alongside CONTRIBUTING.md. MIT is permissive: it lets you use, modify and redistribute the code with the copyright notice and permission notice retained. That covers the automation layer and the Community Edition material in the repository. It does not automatically cover the Enterprise Edition, which the README describes as carrying a commercial licence. If you plan to redistribute Autobase inside a product, or to run the extended management features, the licence boundary between the two editions is the thing to read carefully. This is a description of what the files say, not legal advice; a lawyer should confirm how the split applies to your distribution model.

On maintenance, the repository is not archived, and the last push was on 2026-09-08. Releases are frequent and versioned: 2.11.0 on 2026-09-06, 2.10.0 on 2026-08-02, 2.9.0 on 2026-07-05. That cadence, roughly monthly, is the practical upgrade cost. Because the automation layer is an Ansible collection, upgrading means updating the collection and re-running playbooks, and the repository includes a renovate.json at the top level, which indicates dependency updates are automated on the project's side. What the README does not describe is a supported upgrade path between Autobase versions for an existing cluster, or a compatibility policy for collection versions. The README also states the project relies on sponsorship and support packages to fund continued development, which is worth knowing when you assess how the free tier will be resourced over time.

Editorial conclusion

Autobase fits teams that already run their own Linux servers and want managed-database behaviour for PostgreSQL without handing data to a cloud provider. It is the wrong tool if you cannot give it dedicated hosts, if you need a Windows or macOS server target, or if you want a single binary instead of an Ansible collection plus a Python toolchain. Before adopting, verify three things: that your distribution appears in the daily test matrix in the README, that the Community Edition licence covers your use, and what the documentation says about rolling back a failed cluster change.

Frequently asked questions

Official sources

1. autobase-tech/autobase on GitHub
2. License: MIT
3. Project website
4. README
5. Releases