Podman (Rootless-First)
Podman was selected as the underlying engine for its daemonless architecture and rootless execution, isolating application services without root privileges.
$cat README.md↳01 / OVERVIEW
GoPod
A lightweight, single-server PaaS designed for personal home servers and homelabs, focused on essential deployment workflows without the overhead of larger platforms.
TYPEPersonal Project
ROLEProduct & Systems Design
PERIOD2026–Present
LINKS
TECHNOLOGY STACK
SvelteKitGoPodmanCaddysystemd / QuadletLinux
01 / 03
ASSETS / SCREENSHOTS
↳02 / CONTEXT
Why I am designing GoPod
The inspiration for GoPod came from using platforms like Dokploy on personal hardware. The concept of an application-centric deployment workflow is compelling, but existing self-hosted platforms often carry an application stack and control-plane footprint that feels heavy for a personal home server.
Personal servers and homelabs have finite memory and compute. A deployment platform should not tie up substantial RAM just to coordinate services; those resources belong to the actual applications being hosted.
GoPod is not an attempt to compete with broad self-hosted platforms like Coolify or Dokploy, nor does it target enterprise multi-server clusters. It is an exploration of a small, focused PaaS that delivers the essential deployment workflow (Project → Service → Deploy → Domain) with minimal control-plane overhead.
↳03 / PRODUCT DIRECTION
Core design philosophy
/lightweight-core
Designing with a lower resource footprint in mind, using Go and SvelteKit to minimize idle control-plane memory on small hardware.
/essential-scope
Prioritizing the core deployment lifecycle over an extensive feature catalog. Providing enough functionality for comfort without unneeded platform weight.
/single-server-first
Explicitly architected for a single host, deliberately omitting distributed clustering, multi-node scheduling, and complex permission hierarchies.
/application-abstraction
Structuring the primary interface around 'Deploy my application' rather than 'Manage my containers', keeping runtime mechanics in the background.
/infrastructure-inspection
Providing a dedicated inspection view for Podman containers, pods, images, and volumes without letting container management dominate the user experience.
↳04 / TECHNICAL DIRECTION
Architectural foundation
systemd & Quadlet
Exploring native Linux service supervision via Quadlet files, letting systemd manage container dependencies, auto-starts, and health policies directly.
Caddy Server
Caddy handles automatic HTTPS certificate management and dynamic reverse proxying, routing incoming domains straight to application ports.
Go Core Engine
A compiled Go daemon handles container orchestration, Quadlet generation, and Caddy routing APIs with low memory usage and fast execution.
SvelteKit Interface
A lean, responsive web interface built with SvelteKit, delivering a focused deployment dashboard without client-side bundle bloat.
Fedora Baseline
Fedora provides the development baseline for testing native rootless namespaces, SELinux policies, and modern cgroups v2 boundaries.
↳05 / CURRENT STAGE
Current focus & roadmap
Personal home server first
While I could expand into multi-user or team features in the future, my priority right now is solving my own immediate need: a lean, essential tool for a home server with minimal RAM.
Simplicity and learning
Keeping the scope simple and essential allows me to deeply learn Podman internals, rootless container mechanics, and clean Linux systems architecture.
Design before implementation
GoPod is currently in the product, UX, and architectural design phase. Defining service boundaries and user flows upfront ensures the system remains lightweight by design.