Container manager
PodMesh: live migration for Podman containers
PodMesh manages Podman containers on Linux machines that stay free: live-move them with their memory, replicate them onto the hosts you choose, take over if a machine fails. No cluster to join, no replicated filesystem like Proxmox: the manager itself is replicated. You drive it as an agent-human tandem, Jarvis style, minimal interface.
Why leave Proxmox behind
Proxmox remains a fine tool, used a lot here. PodMesh was born from what was missing for our work: moving Podman live, connecting an already busy host, replicating with no cluster, backing up somewhere other than the live copy.
No cluster to join
Each Linux stays itself: server, VM, VPS. You connect for the work, you detach, you rejoin. An already busy host keeps its identity.
The manager is replicated, not the filesystem
On Proxmox, storage follows. Here, the manager facts converge, at best on every host. Only one governs at a time.
The principle, simply
A Podman container runs on a host. You move it live to another host: memory follows, what runs inside does not start from zero. The same technique keeps a replica ready to take over.
Live migration
Proven in the lab between two hosts: the inner counter keeps going, it does not restart at zero.
Podman inside Podman
An outer container carrying another Podman. You move everything together, not one layer alone.
What works in the lab
Measured on the three lab hosts, as a development service. Not packaged yet, no production.
Replicate onto the hosts you want
Per container: onto one host, several, or all. Now or on a schedule. The replica stays ready; it is not an archive.
Takeover if a machine fails
Planned or after a failure: fence the old active host, wait the margin, promote the copy. The agent decides; no automatic timer.
Stable UUIDs, hot host welcome
Hosts and containers identified by UUID. You connect a host with or without Podman on it, detach it, rejoin it, without overwriting it.
Manager replicated at best
Facts converge across hosts, at best on all of them. Only one governs; the service address follows the governor.
Control: see, clone, pause
Inventory, journal, lifecycle, clone, pause, resume, resources, simple move, console. Same operations everywhere.
Still validating
It runs in the lab but it is not finished: proofs, packaging or real cases are still missing.
Signed manifests, verified origin
Today a recovery point says what it holds, not who produced it. Signing is still to be wired in.
Managed network, general volumes
Moving only works with no managed network and no mounted volumes. The rest is refused before anything is touched.
Real fencing, real failure
Self-fencing is proven in the lab. Out-of-band fencing and losing a real machine are still to be proven.
Latest code packaged
What works in the lab is not what is in the APT. The package is one step behind.
ZFS, Btrfs, LVM storage
Continuous disk replication waits for a qualified backend. The dedicated disks are not added yet.
Backup Server: replicating is not backing up
A replica also copies a mistake. The Backup Server keeps something else: what the container was, versioned, elsewhere.
Versioned recovery points
Identity, configuration, volumes, dumps. Design approved, no code yet: you cannot restore from this yet.
Apart from the live copies
Independent of the replicas. Replication does not replace this, and this does not replace replication.
Tandem driving, Jarvis style
As Shaper OS is built as a human-agent tandem, PodMesh is driven as an agent-human tandem: the agent acts, the human decides. Minimal interface, same operations everywhere.
API and CLI first
Clear operations, not scripts. The console and the command line make the same moves.
Full minimal interface
The console can see, replicate, take over. The generic form and the remaining views are coming.
The feat: what Astra solved
Podman instances inside a Podman container, moved from one machine to another. With Xavier, OpenAI Codex (GPT-6 Astra) adapted the vzcriu fork and the reproduction kit for Debian 13. The rest belongs to the original authors, CRIU and OpenVZ.
Separate PID namespaces, reconciled
Two Podmans, two PID spaces. On arrival, the same workload UUID, inner PID 30 found again, the counter moving on (78 then 80). LSM attributes are restored via thread-self across the nested PIDs.
UNIX sockets named via proc-fd
At dump time, proc-fd-relative socket names are resolved. At restore, the getsockname path changes: an app requiring the exact spelling stays disqualified.
Boot ID and crun repainted
After a validated resume, the inner Podman’s cached boot ID and crun’s cached process start time are updated. Deliberately narrow repair: no generic state fix.
Stated limits, public kit
Three measured migrations, 8 to 10 seconds controller-side, with no network or volumes. The reproduction kit is public, memory archives stay private. Rseq worked around, standard move_mount, inner cgroups shared.
What about Shaper OS?
Shaper OS can lean on PodMesh when an activity runs in a container. We do that internally. PodMesh also runs on its own: it is not a Shaper module.
The code and the package, in public
The GitHub repository is the code. The signed APT is the package, one step behind the lab. Both can be read.
Frequently asked
- Why not stay on Proxmox?
- We used it a lot. PodMesh exists for what we did not have there: live Podman, free Linux machines, a replica ready to take over, a Backup Server that is not the live copy.
- Is the takeover automatic?
- No. The agent decides, the machine proves exclusion: fence, margin, promotion. No timer taking over alone in production.
- Is PodMesh Shaper OS?
- No. Shaper OS is the tool for your activity. PodMesh is the container manager.
Coming from Proxmox? Come and see.
Thirty minutes on your case: containers to move, hosts to connect, replicas to plan. The code can be read without a meeting.