How to Build a Home Development Server for Git, Docker Images, Databases, and Preview Apps
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.
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.
Recommended products
NAS & Server Setup
More to Read
How to Build a Dorm-Room Home Server Without Taking Over the Only Desk
A dorm server should fit one small, quiet, low-power service boundary with contained cables, private access, and recovery outside the room.
Why Are College Students Building Personal Servers Instead of Paying for More Cloud Storage?
Students gain storage control and practical systems skills from a personal server, but cloud remains valuable for off-site safety and simple collaboration.
A Recoverable Developer Homelab Setup for Boot-Drive Replacement
Keep the boot disk disposable by moving definitions, persistent state, secrets, and recovery evidence into documented, independently backed-up layers.
