Open-source software has become insanely good.
Today, a small team can self-host tools for automation, analytics, customer support, monitoring, internal dashboards, databases, and collaboration without paying enterprise SaaS prices.
That part is amazing.
The problem usually starts after the first:
docker compose up -d
At first, everything feels simple.
You get a VPS.
Clone the repository.
Add a domain.
Configure SSL.
And your app is live.
Then production happens.
The hidden work behind “self-hosted”
Over time, someone has to think about:
- backups
- SSL renewals
- container updates
- security patches
- monitoring
- disk usage
- database maintenance
- DNS
- logs
- failed deployments
- version compatibility
- restoring from backups
- unexpected downtime
None of these tasks are individually impossible.
The problem is that they keep coming back.
And for a founder, agency owner, or a small engineering team, infrastructure maintenance often isn't the work they actually want to be doing.
The tool was supposed to save time.
Instead, someone slowly becomes the unofficial DevOps person.
A $5 VPS is rarely a $5 VPS
One thing I've started thinking about differently is the real cost of self-hosting.
Imagine your infrastructure costs only $10/month.
Looks cheap.
But if an engineer spends even 2 hours every month checking updates, fixing containers, debugging something, or maintaining backups, the real cost is already much higher.
Then add the bigger risk:
Something breaks when nobody has time to investigate it.
The infrastructure cost was cheap.
The operational cost wasn't.
Agencies have an even stranger problem
This gets more interesting with agencies.
One client needs an automation platform.
Another needs analytics.
Another wants a CRM.
Another has an internal dashboard.
Individually, each deployment seems manageable.
Then six months later, the agency has:
Client A → VPS 1 → n8n
Client B → VPS 2 → analytics
Client C → VPS 3 → CRM
Internal → VPS 4 → dashboard
Different credentials.
Different versions.
Different backup strategies.
Different domains.
And often no single place that clearly answers:
Is everything actually healthy right now?
At that point, infrastructure becomes part of the agency's operational workload.
That's the problem we're exploring with Docklane
We're building Docklane around a fairly simple idea:
Use open-source software without having to operate all the infrastructure behind it yourself.
The user chooses the software.
Docklane handles the operational layer around it.
Things like:
- deployment
- hosting
- domains and SSL
- monitoring
- backups
- maintenance
- updates
- infrastructure management
The goal isn't to reinvent open source.
And it isn't to hide everything behind some magical “one click” claim.
It's to remove repetitive infrastructure work for teams that don't want maintaining servers to become another job.
The hard part isn't deployment
One thing we're already realizing while building this:
Deployment is probably the easy part.
Running:
docker compose up
can be automated.
The much harder questions are:
How should updates work?
Automatically updating every container sounds convenient until a breaking release takes down a production workload.
How should backups work?
A backup existing isn't enough.
Can it actually be restored?
How often?
How long should it be retained?
How isolated should deployments be?
Containers?
VMs?
Separate networks?
Different levels depending on the workload?
Who owns application-level problems?
If the infrastructure is healthy but an application migration fails, where does infrastructure support end?
How do you make managed hosting economical?
If every customer deployment needs manual intervention, you've built a services company rather than a scalable platform.
These are the parts we're currently thinking through.
And they're much more interesting than the initial deployment script.
Why we're building it early with users
We're not pretending we've solved every one of these questions yet.
Docklane is still early.
We've opened pre-registration because I'd rather understand what people actually struggle with before building a giant infrastructure platform based on assumptions.
Right now, I especially want to hear from:
- founders
- developers
- small engineering teams
- automation agencies
- software agencies
- people already self-hosting multiple tools
If you're self-hosting something today:
What is the part you hate maintaining the most?
Backups?
Updates?
Monitoring?
Security?
Deployments?
Or simply keeping track of everything?
We're building Docklane around those answers.
Top comments (4)
The recurring tax in self-hosted infrastructure is rarely the deterministic compute or storage footprint. It is the unpriced option on maintenance labor. A team budgeting a five-dollar virtual machine implicitly underwrites an unbounded liability: someone has to absorb the cognitive interrupt of broken schema migrations, rotated certificates, and corrupted storage volumes during active customer hours.
Once an agency scales to ten isolated customer deployments, that operational drag scales linearly while revenue remains lumpy. Managed layers succeed not by hiding the deployment script, but by pooling that tail risk across hundreds of tenants so single-node failures stop draining engineering hours.
It’s rarely the compute or storage cost that breaks a small team. It is version drift in dependencies. Open source tools rely on dozens of upstream libraries, and managing compatibility matrices for those components becomes a full-time job.
We saw one deployment fail because an underlying Python library updated its required C extension, breaking the container build entirely. The maintenance burden shifts from infrastructure to dependency graph management.
This resonates hard. I ran things on Tencent Cloud and Aliyun for years — powerful infrastructure, but everything around it felt like a chore.
I run six tiny tool sites on Cloudflare now, and the difference isn't really the price ($5/mo, and honestly most of them live on the free tier now). It's that the maintenance labor you're describing mostly evaporated:
My takeaway is the real cost of self-hosting was never the server bill, it was the constant context-switching into ops mode. Did you find any rough tipping point where self-hosting becomes worth it again, or has managed hosting just won outright for you?
For me it's the last one on your list, keeping track of everything. Backups and patches are chores you can schedule, but "is everything healthy right now" across a few hosts is something you have to go and look at. And if you get a railway deployment for a few different websites and you run 100+ services, then "keeping track of everything" basically becomes impossible.