ArchitectureA supervised JVM-class runtime — OLTP on seven engines, OLAP on three. AI-native, MCP-native, observable as plain SQL.Read the architecture
Está viendo la edición Perú. Está viendo la edición Colombia. You're viewing the Pakistan edition. Cambiar a la edición global →Cambiar a la edición global →Switch to the global edition →
Product Release

Podman and Quadlet rootless deployment — the microservice fleet runs as a systemd-managed rootless container

The microservice fleet ships a Podman + systemd Quadlet management script for rootless container deployment. A persistent service.env survives upgrades, host-side JVM diagnostics (jps, jcmd) work against the running container, and no privileged daemon is required.

The microservice fleet now ships a Podman management script with systemd Quadlet integration, targeting rootless container deployment on Linux production hosts. The shape addresses the operational gap that hits enterprises running Docker today : the rootful daemon is a security and audit liability, but the alternatives (rootless Docker, Kubernetes) introduce their own complexity. Podman + Quadlet split the difference — rootless by default, supervised by systemd, no separate daemon.

Why Podman + Quadlet over Docker

  • No privileged daemon. Containers run as the invoking user. Process trees, file ownership and audit logs all attribute correctly without the rootful Docker daemon's docker group escalation pattern.
  • Native systemd integration. Quadlet renders .container declarations into systemd .service units at boot. The container restarts on failure and on host boot through standard systemd machinery — no separate orchestrator, no PID-1 inside the container.
  • Drop-in compatibility. The Podman CLI mirrors the Docker CLI ; existing operator muscle memory ports without retraining.

What ships in this release

  • The management script. A single entry point that installs, upgrades, starts, stops and tears down the microservice fleet. Idempotent : safe to re-run after a failed step.
  • The Quadlet .container templates. One per microservice, declaring the image, the mounts, the network and the systemd dependencies. The script copies them into /etc/containers/systemd/ at install time ; systemctl daemon-reload materialises them as units.
  • Persistent service.env. Generated on first install with the operator's choices — credentials, ports, JVM memory limits. Never overwritten on subsequent upgrades. Carries runtime configuration outside the container image so a new image version inherits the existing tuning.

Operational surface

  • Host-side JVM diagnostics work transparently. jps lists the JVM inside the container as if it were a host-side process ; jcmd <pid> Thread.print attaches and dumps. No configuration, no docker exec, no /jdk mounts — Podman's rootless namespace mapping makes the in-container JVM visible to host-side tooling that runs as the same user.
  • Standard systemd commands. systemctl status, journalctl -u, systemctl restart all work without an additional CLI. Container lifecycle is just another systemd unit.
  • Upgrade is image swap. A new image version is rolled in by updating the .container file and restarting the unit. service.env survives ; the container takes the new bits.

See the feature →

← All posts