Skip to content

Roadmap

What the next development iteration is about. This page is a plan, not a promise: Versioning says what is guaranteed, and this is not it. Items are listed because a decision was taken to do them. When one ships, it moves to the changelog and leaves this page.

Next iteration

Physical backups and point-in-time recovery

The PostgreSQL Kit does logical dumps: portable, restorable into any newer server, verifiable by restoring. What they do not give is a restore to a point in time, and on very large databases the dump window is the problem itself. Physical copying (pg_basebackup, WAL archiving) and point-in-time recovery are a different class of task — the executor has to sit next to the database, not reach it over the network — which is why they are a separate iteration rather than a feature flag on the current one.

Notification channels

Today alerts reach the interface, a webhook and Telegram. That is enough to wire the platform into something else and not enough to reach a team where it already talks. Next: Rocket.Chat first — a hard requirement, not an option — then e-mail, and the chat systems a self-hosted shop is likely to run (Mattermost, Slack-compatible webhooks). Each channel is a delivery, not a rule engine: thresholds, templates and routing stay where they are.

Check servers started from the interface

The bundled check servers are switched on with a compose command on the host; the interface shows the command and notices the result. Starting them from a button would need the platform to reach the Docker socket, which is root on the host, and the core will not hold it. The shape being considered is a small sidecar that proxies the socket and allows exactly two verbs — start and stop — on containers carrying the platform's label, and nothing else. A separate iteration, because the sidecar is the security boundary and deserves its own verification.

Retention by size

Rotation is grandfather-father-son by age and count. What it cannot say is "keep as much as fits in 200 GB": a storage fills up by size, and the platform notices that only when it is almost full. Size-based retention — the oldest copies go when the storage crosses a line, the last verified copy never does — is the fourth item.

Looking inside a copy

A verification says the copy restores and the row counts agree. It does not say what is in it, and the question people actually ask of a backup is a question about contents: which tables are there, how big each one is, does this row still hold what it held in March. Today that means restoring by hand and finding a client.

A section of its own in the PostgreSQL Kit: put a copy up on a check server or on a host you name, connect to it from the interface, and look — the list of tables with their sizes and row counts, and a place to run SQL against the restored copy rather than against production. The database is disposable, which is what makes it safe to poke at: it is a copy on a machine that exists to hold copies.

Likely a paid capability, and that is not settled.

Keeping one database in step with another

A section of its own in the PostgreSQL Kit: a schedule that takes a copy of one database and puts it into another, on purpose and repeatedly. It looks like verification and it is not: a verification restores to find out whether the copy is good and throws the database away, this keeps a second installation current.

The case it is for is the one everybody has: developers working on data from a fortnight ago because refreshing the development database is somebody's afternoon. Production to staging, staging to development, every Sunday night — the same copy the backups already take, put where it is useful instead of only where it is safe.

What it has to answer before it can ship: what happens to the data that is already in the destination, what is not copied over (the accounts and whatever else is not the source's to hand out), and how a schedule that writes over a live database is made hard to point at the wrong one.

Likely a paid capability, and that is not settled.

Proxmox Kit: the first prototype works

A kit of its own, proxmox, written against a live seven-node cluster rather than against the documentation. What it does today:

  • A cluster read whole, every few minutes. One call describes every node, machine, container and storage, and it answers in hundredths of a second — so the kit reads everything each time instead of sampling cleverly. History is kept in three steps: as taken, then folded to an hour, then to a day, with the peak kept beside the average. The screen that sets those steps says what the history weighs now and what it would weigh under each choice.
  • The inventory. Every node, machine and container becomes a platform resource. This is the half that matters: the network kit finds a host by scanning a subnet and can only guess what it is, while Proxmox knows. The two meet on one resource through the MAC address the interface carries, and ownership typed on one is ownership on the other. Where a machine runs a guest agent it also reports its own hostname, and a resource called 10.34.1.17 finally gets a name.
  • Dependencies nobody else draws. A guest runs on a node, its disk sits on a storage, that storage is served by these OSDs on those hosts. Proxmox knows each of those separately and will never say that filling one storage stops eleven machines on four nodes.
  • Observations, with the numbers behind them. Which machines have no copy anywhere; a disk excluded from the backup of a machine that is backed up; a storage on course to be full in twelve days; a solid-state disk near the end of its write life; a node that has promised more memory than it has. Each carries its evidence, because advice without it is an opinion.
  • A dashboard that is assembled, not laid out. Blocks move, widen and can be put away, and where somebody leaves them is where they are next time — per person, because whoever is on duty and whoever pays for the hardware want different things at the top.
  • Power, behind a second token that may not exist. Everything the kit does by itself is reading. Starting, stopping, restarting and moving a machine need a separate token added on purpose; an installation that never adds one has monitoring physically unable to stop a production machine. Hard stops ask for the machine's name in writing.
  • The certificate is pinned. Proxmox ships a self-signed certificate, and this product has no "do not check" option anywhere — so it is the same pinned fingerprint that FTPS, S3 and the registries already use.

What comes next: backups of virtual machines, and then creating LXC containers.

Not planned

Named so that they do not look forgotten. The platform is not a general-purpose monitoring system and not an orchestrator: IPv6 discovery, SNMP/LLDP and automatic L2 topology, filesystem and VM snapshots are outside it. See Security and known limits for what is not done and what is not verified.