From Podman Compose to systemd services to Kubernetes clusters

Seneca Foundation runs an apprenticeship where new engineers build and ship real applications. Over two years I deployed those applications five different ways. The earlier ways weren’t wrong. Each time the scope grew, the old setup stopped fitting. Here is the path, with dates from the git history.

1. Containers on a server: docker compose and podman compose (2024)

The first deployments were containers on a single server. In August 2024 I added Dockerfiles and compose files to the Business Locator app so its API and front end could run together. Compose is the right first step: one file describes the whole app, and docker compose up or podman compose up brings it up.

What broke the model: nothing restarted the stack when the server rebooted or a process died. It ran fine until it didn’t.

2. systemd services for uptime

So I put the services under systemd. Units start at boot, restart on failure, and log to the journal. Reliability on a single host went up immediately.

What changed next: the scope. More projects needed deploying the same way, and the deployment configuration needed to live with the code, not on a server.

3. A full AWS ECS deployment, driven by CI/CD (Aug 2024 to 2025)

Next came a proper cloud deployment. In August 2024 I set up GitHub Actions to build and push images to ECR for all four of the Business Locator’s applications and deploy them as ECS task definitions. Dev Landing followed (merged December 2024). Through 2025, the pipelines grew into test-before-deploy workflows with the deployment configuration kept in the repo, and a shared deploy template so every project shipped the same way.

What changed next: the scope again, and Kubernetes was next.

4. Ripping it all down and learning Kubernetes

So I tore it all down: every ECS service and every pipeline that fed it. Then I learned Kubernetes properly. I worked through Kubernetes the Hard Way to see what a cluster is made of, then self-hosted a Kubernetes machine of my own. That taught me the parts a managed cloud hides:

• Certificates and TLS, issued and renewed automatically.
• Proxmox virtualization, to run and rebuild nodes freely.
• Networking and routing, including my own home DNS server and router.

That personal cluster became the blueprint for my studio’s infrastructure, the Tidan Games platform.

5. Seneca Foundation’s official cluster (Sep 2025 to 2026)

Then I applied all of it to Seneca Foundation’s official Kubernetes cluster, supervised by Harrison, my boss and training mentor during my apprenticeship. The git history shows the build-out:

The ingress rows are the messy part: I changed controllers, tried TLS passthrough, and moved certificate handling twice before settling on a design. Every step is in git and can be reviewed.

I’ve also been studying for the Certified Kubernetes Administrator (CKA) exam.

6. Where it is now

Today I run two clusters, both managed with GitOps:

• Seneca Foundation’s cluster, hosting all of its deployed projects.
• The Tidan Games cluster, for my studio: Helm charts deployed by Argo CD; metrics and logs in Prometheus, Grafana and Loki; self-managed PostgreSQL and Redis; secrets in OpenBao (the open-source Vault fork); and Harbor as the internal registry.

What tearing it down taught me

• Rebuild when the scope changes, not when it breaks. Each stage was right for its moment. Keeping one past that is how you end up with fragile parts.
• Version control is the real platform. The jump that mattered most wasn’t ECS or Kubernetes. It was the configuration moving into git, so every change is reviewable and repeatable.
• Managed services hide the fundamentals. Self-hosting forced me to understand certificates, DNS, routing and storage. That’s what I need when something breaks at 2 a.m.
• Have a mentor review your work. Harrison questioned every decision on Seneca’s cluster, and the design is better for it.