How to Build a Home Development Server for Git, Docker Images, Databases, and Preview Apps

Eva Wong

IceWhale author

Eva Wong is the Technical Writer and resident tinkerer at ZimaSpace. A lifelong geek with a passion for homelabs and open-source software, she specializes in translating complex technical concepts into accessible, hands-on guides. Eva believes that self-hosting should be fun, not intimidating. Through her tutorials, she empowers the community to demystify hardware setups, from building their first NAS to mastering Docker containers.

How to Build a Home Development Server for Git, Docker Images, Databases, and Preview Apps - Zima Store Online

Build one stable service plane, separate persistent data from rebuildable artifacts, and make every developer service recoverable without preserving the host itself.

For one or two developers at home, a single Linux server can host Git, an image registry, databases, and preview applications. The design stays manageable only when identity, storage roles, network exposure, backup, and restore are planned before the services begin depending on one another.

Assign Service Roles Before Choosing Hardware

Treat Git, the container registry, database engines, and preview applications as separate service roles even when they share one host. Git preserves source history; the registry stores rebuildable artifacts; databases hold mutable application state; preview apps are disposable runtimes.

Estimate CPU and memory from concurrent builds, database working sets, and active previews. Estimate storage from repositories, registry retention, database growth, logs, and backup staging. This avoids buying a large disk while leaving memory as the first bottleneck.

Use one compute node initially when its failure is acceptable for development. Split build workers later if bursty compilation begins starving the databases or interactive previews.

Separate Persistent, Rebuildable, and Recovery Data

Data role	Examples	Protection
Persistent state	Git repositories, database volumes	Snapshots plus independent backup
Rebuildable artifacts	Container images, build cache	Retention policy; optional backup
Secrets and config	Deploy keys, environment files	Encrypted export and offline recovery copy
Recovery media	OS installer, restore notes	Stored outside the server

Do not back up every byte equally. A registry can usually be rebuilt from source and build instructions; a database cannot. Store database dumps or consistent snapshots separately from the live database volume.

One practical self-hosted backup plan demonstrates the value of automating Git and off-site copies as distinct jobs rather than assuming the NAS itself is the backup.

Create One Private Access Path

Give the server a stable LAN address and local DNS name. Expose Git, registry, database, and preview routes only to the networks that need them. Remote access should enter through a private VPN or authenticated reverse-proxy path, not through a collection of forwarded service ports.

Use separate service accounts and deploy keys. Developers should not share an administrator password, and preview applications should not inherit credentials that can modify Git repositories or the registry.

Choose SMB or NFS only for file workflows that truly need a shared mount. The SMB and NFS client-fit guide helps keep protocol choice separate from application service access.

-15% OFF

ZimaBoard 2 - Mini Home Server for Your Big Idea

Single board computer zimaboard2

Make Deployment Order Match the Dependency Graph

Bring up storage mounts, identity, databases, registry, Git, then preview applications. Health checks should test real dependencies without restarting a slow database simply because an application is still warming.

Keep deployment definitions, schema migrations, and reverse-proxy routes in version control. Keep secrets outside the repository and make their restore location explicit. A replacement host should be able to recreate services from definitions plus protected state.

Validate by rebuilding one preview app from a clean checkout, pulling its image, applying a test database restore, and reaching it from the intended client path.

Back Up for Restore, Not for Collection

Back up repositories, database-native dumps, service configuration, and encrypted secrets to a destination that is not mounted writable by every service. Keep at least one copy outside the server's power and administrator boundary.

Run a quarterly restore into an isolated namespace. Confirm users, extensions, scheduled jobs, repository permissions, registry authentication, and DNS routes—not just file presence.

Expand when build queues delay interactive work, database latency rises during image pushes, or backup windows overlap the workday. Stop adding roles to the same host when one experimental service can exhaust resources or credentials needed by the stable service plane.

Final Setup Rule

The setup passes when every service has a named role, protected state, controlled access path, tested restore, and a measurable trigger for splitting or expanding the topology.