DEV Community: Saimul Islam

10 Essential Tools I Actually Use to Keep My Side Projects From Falling Over

Saimul Islam — Sun, 06 Sep 2026 12:47:56 +0000

Docker management, monitoring that goes deeper than a green dot, backups I have actually restored, and everything else that showed up once deploying stopped being the hard part.

Moving off Vercel solved exactly one problem: deploying. Everything else I used to get for free, quietly, as part of the platform, I now had to go find and wire up myself. A month into running my own server, I had a list of ten tools taped to the inside of my head, each one solving a problem I did not know I had until it happened to me at a bad time.

This is that list, in the order I actually needed them, with the mistake or the moment that made me install each one. I lean JS and Rust wherever I can, partly out of preference and partly because those are the tools that keep pace with how fast the rest of my stack moves. A couple of these are not JS or Rust at all, and I kept them anyway because they were simply the best tool for the job.

1. Dokploy, for everything I wrote about yesterday

This is the one I already spent an entire post on, so I will keep it short here. Push to main, Dokploy builds the container, Traefik points a domain at it, done. Four apps running on one $24 droplet, and adding a fifth would not move the bill. If you deploy anything with Docker and are still doing it over SSH, start here. Everything else on this list assumes you already have a platform under you, not just a server.

2. Neon, for the database half of preview environments

The first crack after Dokploy was previews. Dokploy gives every pull request its own preview URL, which is one of the nicest things about the whole setup, right up until every preview hits the same production database. I corrupted a batch of test data twice before I noticed what was happening. Neon branches Postgres the way git branches code, copy-on-write, so a preview PR gets its own preview database that costs almost nothing until it actually diverges from main. The storage engine underneath is written in Rust, and it quietly closed the other half of preview environments that nobody's setup guide mentions.

3. OpenObserve, for monitoring that actually explains itself

Dokploy's own dashboard will tell you a container is using too much memory. It will not tell you why, which request caused it, or whether it has happened before. I moved to OpenObserve for that: logs, metrics, and traces in one place, shipped as a single Rust binary, one docker-compose file to run it. The first afternoon I had it wired up, I found a query that had been running slow for three weeks, in the trace waterfall, in about four minutes. My old approach to that same investigation was grep and vibes.

4. restic, for the backups Dokploy does not know about

Dokploy's built-in backups cover Postgres, and I use them. They do not cover the config folder for my API, a SQLite file one of my smaller tools writes to, or a volume attached to a service that is not a database at all. restic backs up anything, encrypts it before it leaves the box, deduplicates so a nightly backup of a mostly-unchanged folder costs almost nothing in storage, and restores with one command I have run on purpose more than once, just to check.

restic -r s3:https://<account>.r2.cloudflarestorage.com/backups backup /var/lib/myapp
restic -r s3:https://<account>.r2.cloudflarestorage.com/backups restore latest --target /tmp/restore-test

It ships as a single static binary, which after living through more dependency hell than I would like to admit, I have come to treat as a feature in its own right.

5. Sentry, for the bugs logs make you scroll past

Logs tell you something broke. They do not tell you it broke for the same handful of users, three times a day, on the same line of code, until you have already lost interest in scrolling through them. Sentry groups the exception, attaches the stack trace, and tells me exactly which release introduced it. The self-hosted stack is heavier than I would like, but the JS SDK alone, dropped into a Next.js app, has caught more real bugs before a user reported them than anything else on this list.

6. OpenReplay, for the tickets that just say “it's broken”

A user once emailed to say a form “just doesn't work,” with no other detail, which used to mean opening dev tools and hoping I could reproduce it. OpenReplay records the session and replays it back like a video, console errors and network requests included, exactly as the user hit them. It is open source and self-hosted, and it has turned half-day investigations into two-minute videos more times than I can count.

7. Appium, for testing on an actual device instead of a hunch

Once a project had a real mobile wrapper around it, testing it by hand on my one physical phone stopped being a strategy. Appium drives real devices and simulators the same way Selenium drives a browser, through the WebDriver protocol, so the same testing habits carry over. I script the login flow and the checkout flow on both iOS and Android before every release, and it has caught two platform-specific bugs that a browser would never have shown me.

8. k6, for finding the ceiling before traffic does

A newsletter mention once doubled my traffic for six hours. The API held, barely, and I had no idea by how much margin. k6 lets me write load tests in JavaScript, the same language as the thing being tested, and run them against staging before a launch instead of finding the ceiling live.

import http from 'k6/http';
export const options = { vus: 500, duration: '2m' };
export default function () {
  http.get('https://staging.myapp.com/api/health');
}

Ten minutes to write that tells you more than any amount of guessing.

9. Infisical, for replacing a very bad system

My “secrets management” before this was environment variables pasted into Dokploy's UI and, if I am honest, a couple of .env files sitting in a private Slack channel. Infisical is open source, written in TypeScript, and gives every project versioned secrets, per-environment values, and an audit log of who changed what. Rotating a leaked key used to mean a search-and-replace across three servers. Now it is one dashboard and a redeploy.

10. n8n, for the glue that runs everything else

n8n is the part that quietly holds the other nine together. When OpenObserve crosses an alert threshold, when a restic backup fails, when a new signup needs a welcome sequence, n8n is the thing that notices and does something about it, wired together as a workflow instead of a script I will forget I wrote. It runs on Node, it is free to self-host, and it is the tool I have extended the most since installing it, because every new problem seems to end with “I should probably wire that into n8n.”

So, is this too many tools for a side project?

Maybe. Ten tools running on one box is still one box, and the more of these you add, the more you are choosing to own instead of rent. What changed for me is that each one solves a problem I actually had, in the order I actually had it, rather than a checklist I installed on day one and mostly ignored. If you are one platform migration into doing this yourself, start with whichever one of these already hurts.

Sources and further reading

Stop Paying for Vercel: How to Self-Host Your Deployments on a VPS and Keep the Same Workflow

Saimul Islam — Fri, 04 Sep 2026 05:19:58 +0000

Push-to-deploy, automatic HTTPS, and preview environments on a $24 droplet with Dokploy, plus the four mistakes to skip on the way.

For two years, deploying was the easiest part of my week. I pushed to main, closed my laptop, and the site updated itself. I never thought about servers, which was the entire point of paying for it.

Then I opened the invoice.

$198 for the month. I read it twice, because the number did not match what I was running: a Next.js frontend with a few thousand monthly visitors, a small API moving JSON around, one Postgres database holding a couple hundred megabytes, and a nightly cron job. Four small things, and I knew that launching a fifth would push the bill up again.

Here is what is worth understanding before you decide whether any of this applies to you. You are not paying managed platforms for compute. Compute is cheap. You are paying because somebody else already set up the reverse proxy, the TLS certificates that renew themselves, and the pipeline that turns a git push into a running container. That is real work, and it was worth every cent for two years. So the question got narrower: is it still worth it, now that I know which of those features I actually use?

What follows is the whole setup, end to end: installing Dokploy, connecting your Git provider, getting deploys on every push, domains with automatic HTTPS, object storage for user files, scheduled backups, and monitoring. The workflow you land on is the one you already have. You push to main, you close your laptop, and the site updates itself.

It took me a weekend, and I have left all four of my mistakes in, because those are the parts no documentation warns you about. If you can ship an application but have never really run a server, this is written for you.

Why My First Attempt at This Failed

My first instinct was to do it entirely by hand, and that failure is the reason Dokploy made sense to me later. I rented a VPS, installed Node, set up PM2 to keep the process alive, hand-wrote an Nginx config, and ran Certbot for a certificate. I felt clever for about four days.

Then deploying turned out to mean SSH-ing in to run git pull, which is fine right up until you are doing it from your phone because something has broken. No build logs, no deployment history, and a rollback plan that was really just hope. Adding a second app meant another Nginx block, another port, another process to babysit.

The problem was never that servers are hard. It was that I had hand-built a worse deployment platform and was now responsible for maintaining it. Once I wrote down what I actually wanted, it became shoppable: something that handled the reverse proxy, the certificates, the builds, the restarts, and the rollbacks, on hardware I paid for directly. That is what Dokploy is. So I went and got a server to put it on.

Choosing the Server, and the Mistake I Made in the First Hour

I went with DigitalOcean. Hetzner, Vultr, and OVH are all fine too, and cheaper if you are optimising purely on price, but I already had projects there and wanted one dashboard rather than four.

Dokploy says the minimum is 2GB of RAM. That is technically true and practically a trap, because you build your application on the same box you deploy to.

I found out the hard way. My first build died on the $12 droplet. Not failed, died. The log stopped part way through with no error, and I spent twenty minutes blaming my Dockerfile before finding the kernel had killed it for using too much memory. Skip the entry tiers and start on the 4GB droplet at $24, which fits the app, the database, and the build at once. Ubuntu 24.04, because boring is correct here.

One more thing before you install anything, and I nearly skipped it. Ten minutes on the basics: SSH key instead of password login, password login disabled, firewall with ports 22, 80, 443, and 3000 open. When I checked my auth log a day later there were thousands of failed login attempts. Nobody knew my server existed. That is simply what the internet does to a public IP.

With the box locked down, the install itself is almost anticlimactic.

Installing Dokploy Takes One Command

curl -sSL https://dokploy.com/install.sh | sh

A few minutes of output, and it is done. It is worth seeing what that script did for you, because you now own a real stack rather than a magic box. It installed Docker, set up Swarm mode so containers restart on their own when they die, deployed Traefik as your reverse proxy, and started a small database for Dokploy itself. Every one of those I configured by hand the first time, and got wrong at least once.

Open your server IP on port 3000 and create an admin account. Then, before deploying anything, point a subdomain like panel.yourdomain.com at the server, give the dashboard that domain, turn on HTTPS, and close port 3000. Your control panel should not sit on an open IP with only a password in front of it.

You now have a platform. What it does not have yet is your code.

Connecting GitHub Is the Decision That Pays Off Later

Dokploy pulls your code two ways, and the choice matters more than it looks at the time. The first is a generic Git connection over SSH, which works with GitLab, Bitbucket, Gitea, or anything else that speaks SSH. Generate a key in the SSH Keys section, add the public half to your provider, and use the git@ URL rather than https.

The second, if you are on GitHub, is the Dokploy GitHub App. Two extra minutes, and it is the best decision in this story. That single step gave me automatic deploys on push, watch paths, and preview environments for pull requests, with no further configuration. Those are exactly the three things people assume they give up when they leave managed hosting, and this is where you keep them. Click the right button early, because switching later is far more annoying.

Then create a project, pick your repository and branch, and paste your environment variables into a box that works like a .env file. One detail that confused me: Dokploy clones the repository onto your own server and builds it there, which is why server memory mattered so much a moment ago.

Then I hit deploy. And then I hit it three more times.

My First Three Deploys Failed, and That Was the Useful Part

Every tutorial I read showed a green checkmark on the first attempt, so when mine went red I assumed something was structurally wrong. It was not. Three ordinary mistakes, each of which explained a piece of how the system fits together.

1. The Port

The build worked, the container started, and the site returned a gateway error, because I had never told Dokploy which port my app listens on. That field lives in the domain settings rather than the build settings, which is why I missed it. The lesson is worth keeping: your app is never exposed to the internet directly. Traefik forwards public traffic inward, which is why you never open your app port in the firewall.

The path a request takes, and why the container port lives in the domain settings.

2. Missing Environment Variable

The second was a missing environment variable. It built fine and crashed on startup, and the container log said so in its first line while I was staring at the build log. Those answer different questions: why it would not compile, versus why the compiled thing will not run.

3. The Build Type

The third was the build type, which is how Dokploy turns your repository into a running app at all. There are five options, and the default guesses for you.

If your project is	Choose
A standard Next.js, Django, or Laravel app	Railpack, the modern default, or Nixpacks if it gives you trouble
Already carrying a Dockerfile you trust	Dockerfile, for full control including build secrets
A static site from Vite, Astro, or Hugo	Nixpacks with a Publish Directory, or Static if pre-built
Being moved directly off Heroku	Buildpack, using your existing Heroku or Paketo config

I switched to a Dockerfile because my build needed a step the automatic builders were skipping. Fourth deploy, green checkmark. The site loaded, at an IP address, which did not feel like it counted yet.

Giving It a Real Domain and Free HTTPS

This happens in two steps, and doing them in the wrong order caused my next mistake. At your registrar, create an A record pointing your domain at the server IP. Then in Dokploy, open your app, go to Domains, and add one. Set the Host, Path, and Container Port, flip the HTTPS toggle, choose Let’s Encrypt, and the certificate and its renewal are handled from then on.

My mistake was enabling HTTPS fifteen seconds after creating the DNS record. Let’s Encrypt tried to verify I owned the domain, found nothing, and failed with an error that never mentioned timing. Run dig +short yourdomain.com first, and only enable HTTPS once it prints your server IP back.

One more trap catches a lot of people. If your DNS is on Cloudflare, the orange cloud means Cloudflare is proxying your traffic, and verification fails with an error that never mentions Cloudflare either. Set the record to DNS only until the certificate is issued, then switch proxying back on if you want it.

While you are in the dashboard, add Postgres too. Resist the urge to expose its port, because open database ports are among the most scanned things on the internet. Your app reaches it by service name over the internal Docker network, as in:

postgresql://user:pass@my-app-db:5432/mydb

And that was the setup finished. Custom domain, valid certificate, deploys on push, a database, all for $24 a month. It ran perfectly for two weeks, which is when the real education started.

Two Weeks In: The Monorepo Problem

The first crack was small. My repo is a monorepo, and every push rebuilt everything in it. I would fix a typo in a markdown file and watch three services redeploy and send me notifications for things that had not changed.

Watch paths fix this. In your app’s Git settings you list the files and folders that app actually cares about, and it only rebuilds when something inside them changes:

apps/web/**
packages/ui/**
!apps/web/**/*.md

Two asterisks match across directories, and a leading exclamation mark excludes. One caveat before you go debugging: this works out of the box on GitHub, but on GitLab, Bitbucket, or Gitea you need automatic deployment working first, because watch paths filter automatic deploys. With nothing to filter, they look ignored.

That one was an annoyance. The next one was not.

Three Weeks In: The Day All My User Uploads Disappeared

I shipped a routine change, nothing dramatic, and somebody told me their profile picture was gone. Not just theirs. Every file any user had uploaded since launch.

The cause is obvious in hindsight and catches almost everyone new to containers. I had been saving uploads to a folder inside the application, so when I deployed, Dokploy built a fresh container from my repository and replaced the old one. My repository does not contain user uploads. Containers are meant to be disposable, and that is exactly what makes deploys and rollbacks safe. My mistake was putting data that has to survive inside a thing designed not to.

Why the uploads vanished, and where they should have been living instead.

For user files the answer is object storage, and I picked Cloudflare R2 for one reason: it charges nothing for egress. Everyone else charges you to read your own files back out, and that cost scales with traffic rather than storage. R2 is $0.015 per GB per month with zero egress, against roughly $0.023 per GB plus $0.09 per GB egress on S3, and the free tier covers 10GB and 10 million reads a month.

Best of all, R2 speaks the S3 API. Create a bucket, generate an API token with Object Read and Write, note your account ID, and point your existing S3 client at it:

import { S3Client } from "@aws-sdk/client-s3";

const s3 = new S3Client({
  region: "auto",
  endpoint: `https://${ACCOUNT_ID}.r2.cloudflarestorage.com`,
  credentials: { accessKeyId, secretAccessKey },
});

Setting that up turned out to be lucky, because a few days later I needed somewhere to put backups.

The Night I Realised I Had No Backups at All

I was running a migration late one night, and for about ninety seconds I believed I had destroyed my users table. I had not, in the end. But in those ninety seconds I went looking for my backups and found something worse than a bad migration. There were none. Three weeks of production data, not a single copy anywhere.

The embarrassing part is that Dokploy had this built in the whole time, in a tab I had scrolled past a dozen times. On the schedule you set, it runs a proper database dump, the same pg_dump you would run by hand, and ships it to S3-compatible storage. Which is why the R2 bucket from the last section quietly became my backup destination too, on the same free tier.

Add the destination once under Settings, then Destinations, using your R2 access key, secret key, bucket, the region set to auto, and the same endpoint as above. Hit the test button before you trust it, because a destination that fails silently is worse than none. Then open your database, go to Backups, and set a schedule. I use 0 3 * * * for daily at 3am.

Now the part that matters more than everything above it. A backup you have never restored is not a backup, it is a file you feel good about. The week after setting this up I spun up a throwaway Postgres service and restored into it on purpose. Ten minutes, and it worked. Do that once while nothing is on fire. Then be as pleased with yourself as I was, right up until you try to back up the next thing.

What to Do When There Is No Database to Back Up

My other service had no database. It kept its state in a folder, which is the shape of anything using SQLite or any self-hosted tool with a working directory, so the backup feature had nothing to point at.

Dokploy handles this with volume backups, which meant finally understanding a distinction I had been ignoring. A bind mount points at a folder on the host machine. A named volume is storage Docker itself creates and manages, referred to by name. I assumed that was stylistic. It is not, because volume backups only work with named volumes, so a bind mount means migrating first.

Creating one is easy. Go to Advanced, then Mounts, and add a Volume Mount with a name like app_data and the path where it appears inside the container. One detail that will confuse you at restore time: for Compose services, Dokploy prefixes the volume name with the app name, so app_data exists as myapp-abc123_app_data.

You also choose whether to stop the container while the backup runs. Stopping is safer, since nothing is writing while files are copied. I stop mine, because forty seconds of downtime at 3am costs nothing and a corrupted backup would cost a great deal.

The finished storage setup: uploads written live, database and volumes backed up on a schedule, all into one bucket.

With that, my data was safe. So naturally the server got slow.

A Month Later: Why Is Everything Suddenly Slow?

Everything got sluggish at once, across all my apps, which is the least helpful symptom possible because it tells you the problem is shared and nothing more.

Under my old setup I would have SSH-ed in, run top, squinted at container-generated process names, and guessed. Instead I opened the dashboard, where every application has its own view of CPU, memory, disk, and network usage. I found the culprit in two minutes: a background job in my API had a runaway loop and was eating almost all the memory on the box. Live logs and deployment history did the rest. A surprising number of mysteries resolve the moment you notice the slowdown began at the exact minute of a deploy.

I fixed the loop, obviously. More usefully, I set a memory limit on that app under Advanced, then Resources, so it can never take the whole server down again. If it exceeds the limit it restarts rather than consuming everything around it. I now set limits on everything at double normal usage, plus alert thresholds pointed at Discord so the server tells me before a user does.

Worth being straight about the limits. Self-hosted gives you per-container metrics, logs, deployment history, resource limits, and threshold alerts. The advanced dashboard is part of Dokploy’s paid cloud tier. For a handful of apps the built-in view is plenty, and if you outgrow it, Dokploy ships a Prometheus extension as a template that gives you Grafana on the same box.

That is the last of my four mistakes. One more warning, though, and it is the thing that quietly kills self-hosted setups around the three month mark.

The Thing That Will Break in Three Months

Your disk will fill up. Every deploy builds a new Docker image, and old images and build caches do not delete themselves. You go from comfortable to out of space with no warning at all, and your deploys start failing with errors that never say "disk full".

df -h                    # how much space is left
docker system prune -af  # remove unused images and caches

Run that occasionally, and update Dokploy itself from the dashboard every month or so, since it is your software now.

So, Was It Worth It?

$198 a month became $24, and R2 is still inside the free tier. It cost me a weekend including every mistake above, and about thirty minutes a month since. Nothing about my day-to-day changed: deploy on push, automatic HTTPS, preview environments, and one-click rollbacks all survived the move. That droplet now runs four applications instead of one, and adding a fifth would not change the bill.

What I gave up is real, and I would rather say it plainly than sell you something. One server is one point of failure, and if the machine dies, everything on it is down until I bring it back. My answer is backups I have actually tested, and knowing a fresh server plus a restore is a couple of hours rather than a catastrophe.

So do not do this if you are pre-launch and your only real job is shipping features, because every hour on infrastructure then is an hour not spent finding out whether anyone wants the thing. Do not do this if nobody can respond when the server has a problem, because a managed platform is partly an on-call rotation you are renting. And if your traffic is global and latency-sensitive, remember that one server is in one place.

What I got beyond the money mattered more than I expected. Deployment used to be a black box I posted code into and hoped about. Now I know what a reverse proxy does, why containers are disposable, and where my data actually lives. The anxiety about next month’s bill is gone too, not because $24 is nothing, but because it does not move when I have a good week.

If you want to try this, rent a box, spend ten minutes on SSH keys and a firewall, run one install command, and deploy something small you would not mind breaking. Give yourself an afternoon. Worst case, you destroy a server costing a few dollars and start again, which is a cheap way to learn how your own infrastructure actually works.