This is my setup running on a "vintage" HP Z440 server with modest specs:
- Intel Xeon E5-2683 v4 @ 2.1GHz (16 core/32 thread)
- 32GB ECC DDR4
- Array pool: 2 x 4TB HDD, 1 x 2TB HDD, 1 x 6TB parity HDD
- Cache pool: 1 x 1TB SSD
- NVIDIA Quadro M2000 4GB
This isn't a particularly powerful machine by modern standards. It's simply the box I have, and it handles my development environment quite comfortably.
The Basic Idea
The easiest way to understand my environment is to think of it as a small private cloud.
Instead of installing every tool directly on my workstation, most services run as containers on the server. Projects can consume shared services when that makes sense, or bring their own private infrastructure when portability and isolation are more important.
The result isn't particularly exotic. It's mostly a collection of open-source projects doing very specific jobs.
There are two ways I tend to deploy infrastructure:
Shared infrastructure — one service, multiple projects.
Project-local infrastructure — the service lives inside the application's deployment.
In development I favor convenience and use a shared PostgreSQL instance. In production I favor isolation: each Coolify project gets its own database, so a compromise of one application's database doesn't automatically expose every other application's data.
For projects intended to be portable or handed to someone else, I generally prefer project-local infrastructure. The entire application can then be deployed with its dependencies rather than relying on services that happen to exist on my server.
The List I Use
This isn't intended to be a definitive list of services everyone needs.
It's the stuff I actually use.
Deployment & Infrastructure
Coolify
My primary deployment platform.
- Containerized deployments
- CI/CD, including automatic deployments from Git
- Built-in Traefik proxy
Nginx Proxy Manager
Reverse proxy for services outside the Coolify-managed environment.
It provides a simple UI for routing domains and managing certificates.
Go-static
A lightweight static web server.
I use it for things like Svelte landing pages where I don't need an entire application stack.
Redis
Caching and other transient data needs.
Storage & Databases
Appwrite
An integrated backend platform when I want several services together:
- S3-compatible object storage
- Authentication
- Database
- Messaging/notifications
- Other application services
It's useful when I want the convenience of having those pieces available as one platform.
VersityGW
When I only need object storage, I don't necessarily want the rest of a backend platform.
VersityGW provides S3-compatible object storage while staying relatively lightweight and barebones. I typically deploy it privately alongside the application that needs it.
PostgreSQL / MariaDB / Mongo
Data persistence.
I use shared instances during development when convenience makes sense, and private instances within project deployments when isolation or portability matters.
Databasement
Database backups.
Eventually somebody will delete something important.
Source Control & Development
Forgejo
My private Git instance.
It provides local access to my repositories while allowing projects to be mirrored to GitHub for redundancy.
ByteStash
A private snippet manager, including an MCP server for agent access.
IT Tools
A collection of common development utilities — token generation, JSON conversion, and more.
SearXNG
My private search provider.
Agent Infrastructure
This is where the environment starts to reflect what I'm currently working on.
mem0-aio
Agent memory infrastructure.
Kanboard
A private Kanban system with an MCP server for agent access.
I'm increasingly interested in infrastructure that an agent can interact with directly rather than treating the development environment as something completely separate from the agent.
That's one of the directions I'm exploring with ICOS.
Documents & Content
Paperless
Document management and OCR.
It automatically processes documents and supports AI-assisted document classification and extraction.
Cloudreve
Cloud document storage.
Honorable Mentions
Not everything on the server exists specifically for software development.
homepage provides a central overview of the services running on the server.
Krusader and Manyfold help catalog my 3D-printing assets.
Immich provides Google Photos-style image storage with machine-learning features.
Mealie manages recipes, including importing them from URLs.
Booklore manages my ebook collection.
They're not essential to writing software, they're just useful. That's one of the nice things about having your own infrastructure: once you have the platform, it can support more than one purpose.
So Why Do I Have All This Stuff?
There is a little more history behind this environment than "developer discovers Docker."
Before I became a software developer, I spent roughly 10–15 years working with hardware and IT systems.
I was a bench technician, field technician, implementation technician, Tier 2 helpdesk technician, and refurbishment technician working in recycling depots. I was managing hardware and server stacks long before I knew what CSS was.
I've worked with Windows Deployment Services, Active Directory, DHCP/DNS, SCCM, and Windows Server 2012-era infrastructure. I was never a dedicated server administrator, and I don't claim to be an infrastructure expert.
But I knew how to wrangle a PC.
I knew how to deploy systems, troubleshoot hardware, chase down network problems, and figure out why something that should work wasn't working.
I also spent time studying for certifications that I couldn't afford to actually sit:
- CompTIA A+
- CompTIA Server+
- Microsoft MCP — Windows Desktop
- MCSA Server 2012
- AVIXA CTS
I don't list those as certifications, because I never earned them, but the knowledge I gained while studying for them didn't disappear just because I couldn't afford the exam.
The Foundation
One thing I've noticed as I've moved deeper into software development over the years is that a lot of the problems aren't actually new problems.
- The technology changes.
- The layer changes.
- The terminology changes.
But troubleshooting is still troubleshooting.
- Something isn't working.
- Figure out what it's supposed to do.
- Determine where reality diverges from expectation.
- Isolate the problem.
- Change one thing.
- Test it.
- Repeat.
That's as true for a Docker container talking to PostgreSQL as it was for a workstation that wouldn't boot.
Software development added a huge amount of new territory for me: application architecture, APIs, databases, distributed systems, frameworks, algorithms, and a pile of things I didn't know existed when I was repairing computers.
I'm still learning. I'll probably still be learning when I'm 70.
But I didn't start from zero, I started with a decade-plus of learning how to make complicated systems behave. Software just gave me another layer to work on.
You Don't Need This
None of this is a recommendation that everyone should go build a server closet.
You absolutely don't need one.
You can develop software perfectly well with a laptop, GitHub, Docker Desktop, and whatever hosted services your project needs. This is simply the environment that makes sense for the way I work.
It gives me control over my development infrastructure, lets me experiment with different technologies, gives my agents access to services they can actually interact with, and lets me build deployments that can eventually leave my little server entirely.
The infrastructure isn't the point. It's another tool.
Just like the extensions in VS Code, these are the tools I've accumulated because they solve problems I actually have, and there are probably another hundred things I've forgotten to mention. That's what happens when you spend enough years building your own toolbox.
The hardware came first. The software came later.
Now there's just considerably more TypeScript involved. 😂
Top comments (0)