Self-Hosting Taught Me That Deployment Is an Engineering Problem

I used to think of deployment as the final step after development.

Build the application.

Push the code.

Deploy it.

Done.

Working with my own VPS changed that perspective.

When you deploy your own application, you become responsible for much more than the application code.

You have to think about the server, networking, containers, domains, HTTPS, environment variables, logs, updates, and security.

My deployment stack

The setup I'm working with looks roughly like this:

GitHub
   ↓
Coolify
   ↓
Docker
   ↓
Application
   ↓
Reverse Proxy
   ↓
Domain
   ↓
Internet

`

The interesting part is that every layer can fail independently.

Your application can be perfectly fine while the deployment is broken.

For example:

text
Application works locally
↓
Docker container starts
↓
But the port is wrong
↓
Reverse proxy can't reach it
↓
Domain shows an error


From the browser, all you see is:

"The website isn't working."

But the actual problem might have nothing to do with your application code.

A VPS forces you to understand the infrastructure

With managed hosting, many infrastructure decisions are hidden from you.

That's convenient.

But when something goes wrong, you may not understand what is happening underneath.

With a VPS, you start seeing the actual layers:

text
Linux
↓
Docker
↓
Container
↓
Application
↓
Network
↓
Reverse Proxy
↓
DNS
↓
HTTPS


That's more responsibility, but also more learning.

Coolify makes the process easier

Using Coolify means I don't have to manually manage every deployment command.

I can connect a repository, configure the application, provide environment variables, and let the platform handle much of the deployment workflow.

But Coolify doesn't remove the need to understand infrastructure.

It just moves the repetitive work away from the command line.

If something fails, I still need to understand whether the problem is:

text
Git
Docker
Application
Environment
Network
DNS
Reverse Proxy
Server


That's where the real learning happens.

DNS is part of deployment

One thing that's easy to overlook is that your application isn't truly accessible just because it is running on the VPS.

The domain needs to point to the right server.

The traffic needs to reach the correct service.

HTTPS needs to be configured.

So the complete path becomes:

text
User enters domain
↓
DNS resolves domain
↓
Request reaches VPS
↓
Reverse proxy receives request
↓
Request forwarded to container
↓
Application responds


Every arrow represents another possible failure point.

Deployment changes how you write software

Once you know your application will eventually run somewhere other than your laptop, you start making better decisions.

You think about:

• Configuration outside the source code
• Environment variables
• Reproducible builds
• Containerization
• Logs
• Health checks
• Database persistence
• Backups
• Security
• Rollbacks

These aren't "DevOps things" that someone else will deal with later.

They're part of running the software.

The biggest lesson

Self-hosting has made one thing very clear to me:

Writing code is only one part of software engineering.

An application isn't finished when it compiles.

It isn't finished when it works on localhost.

It's finished when you can reliably build it, deploy it, operate it, debug it, and recover when something goes wrong.

I'm still learning these parts by actually deploying and managing my own projects.

And honestly, that's much more valuable than memorizing deployment commands.

Because commands can be searched.

Understanding the system is what stays with you.

devops #selfhosting #docker #coolify #vps #linux #deployment #softwareengineering #buildinpublic

`

Comments

[P O]

the layer-by-layer failure point is so real. one thing that saved me a lot of time was checking each hop separately with curl, then checking the reverse proxy access/error logs, before touching the app. a tiny health endpoint plus a container-level curl test makes DNS vs proxy vs app failures obvious.