DEV Community: overnight.host

Scheduling jobs on a VPS with cron — a practical guide

overnight.host — Wed, 24 Jun 2026 07:16:17 +0000

One of the first things you want from your own server is for it to do things while you sleep: run a backup at 3 a.m., restart a flaky service nightly, pull fresh data every fifteen minutes. On Linux, the oldest and most reliable tool for that is cron. It is on practically every VPS already, it needs no daemon you have to install, and once you understand the five-field syntax it stops being intimidating.

The five fields

A cron schedule is five space-separated fields, followed by the command:

┌─ minute (0-59)
│ ┌─ hour (0-23)
│ │ ┌─ day of month (1-31)
│ │ │ ┌─ month (1-12)
│ │ │ │ ┌─ day of week (0-7, 0 and 7 are both Sunday)
│ │ │ │ │
* * * * *  command-to-run

A * means "every value." So */15 * * * * is "every 15 minutes," 0 3 * * * is "03:00 every day," and 0 9 * * 1 is "09:00 every Monday." That is 90% of what you will ever write.

Editing your crontab

Each user has their own crontab. Edit yours with:

crontab -e      # opens your personal crontab in $EDITOR
crontab -l      # list current jobs

Add a line and save. For example, a quarter-hourly sync and a nightly backup:

*/15 * * * * /usr/bin/curl -fsS https://api.example.com/sync >> /var/log/sync.log 2>&1
0 3 * * *    /home/deploy/backup.sh

To run something as root (system maintenance, service restarts), use sudo crontab -e, or drop a file into /etc/cron.d/ with an extra username field.

Three things that trip everyone up

1. Cron has almost no PATH. Inside cron, $PATH is minimal, so a bare python or node often "works on the command line but not in cron." Always use absolute paths (/usr/bin/python3), or set PATH= at the top of the crontab.

2. Output goes to mail, or nowhere. If a job prints anything and you do not redirect it, cron tries to email it locally and you never see it. Redirect both streams to a log so failures are visible:

0 3 * * * /home/deploy/backup.sh >> /var/log/backup.log 2>&1

2>&1 is the important half — it captures errors, not just normal output.

3. Timezone. Cron uses the server's system clock. On a multi-region setup your VPS might be on UTC, not your local time. Check with timedatectl, and either do the mental math or set CRON_TZ=Europe/Berlin (or your zone) at the top of the crontab so 0 3 * * * means what you think.

Don't let jobs pile up

If a job can run longer than its interval (a backup that occasionally takes 20 minutes on a 15-minute schedule), guard it with flock so a slow run never overlaps the next one:

*/15 * * * * /usr/bin/flock -n /tmp/sync.lock /home/deploy/sync.sh

-n means "if the lock is held, skip this run rather than queue." Overlapping cron jobs are a classic cause of a server quietly grinding itself to a halt.

When cron is the wrong tool

For sub-minute scheduling, jobs with dependencies, or anything that needs retries and a dashboard, reach for systemd timers or a proper job runner instead. Cron is perfect for simple, independent, time-based tasks — and most of what a small server needs is exactly that.

A quick way to get the syntax right

If you would rather not count asterisks in your head, we keep a free cron expression generator that turns plain-English schedules into the exact five-field line (and explains an existing one back to you). It is one of a handful of small, free tools we host on overnight.host — no signup, just useful. Whether your box lives in an EU or US region, the cron syntax is identical, so the schedule you build there drops straight into crontab -e.

A practical UFW firewall for your VPS — open only what you need

overnight.host — Wed, 24 Jun 2026 07:15:41 +0000

A fresh VPS arrives with every port reachable from the entire internet. Most of them have nothing listening, but the moment you start a database, a cache, or a dev server bound to 0.0.0.0, it is exposed — and bots scan for exactly that within minutes. A firewall flips the default from "open unless I close it" to "closed unless I open it." On Ubuntu and Debian, ufw (Uncomplicated Firewall) makes that a five-minute job.

The golden rule: allow SSH before you enable

The single most common way people lock themselves out of a VPS is enabling a default-deny firewall without first allowing their own SSH port. Do it in this order, every time.

sudo apt install ufw          # usually already present
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow OpenSSH        # or: sudo ufw allow 22/tcp

default deny incoming blocks everything arriving from outside. default allow outgoing lets your server reach the internet (package updates, API calls) normally. The SSH rule is what keeps your session alive after you turn the firewall on.

Only now:

sudo ufw enable
sudo ufw status verbose

If you moved SSH to a custom port, allow that port instead of OpenSSH, and confirm it works in a second terminal before closing the one you are in.

Open the services you actually run

Add a rule per public service. A web server:

sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
# or the named profile if installed:
sudo ufw allow 'Nginx Full'

A game server usually needs a specific UDP and/or TCP port — for example a Minecraft Java server:

sudo ufw allow 25565/tcp

The principle is to map each rule to a service you are deliberately exposing. If you cannot name the service behind a port, you probably should not open it.

Keep databases private

The biggest win is not opening your datastore. Postgres (5432), MySQL (3306), Redis (6379) and friends should listen on 127.0.0.1 or a private network interface, never the public one. If your app runs on the same box as its database, the database needs no firewall rule at all — local traffic never traverses the public interface.

If you must reach a database from another server, scope the rule to that source address rather than the whole world:

sudo ufw allow from 203.0.113.10 to any port 5432 proto tcp

That one line is the difference between "my teammate's server can connect" and "the entire internet can try."

Rate-limit SSH against brute force

ufw has a built-in throttle that temporarily blocks an address making too many connections in a short window — handy for the constant SSH login attempts every public box receives:

sudo ufw limit OpenSSH

It is not a replacement for key-based auth and tools like fail2ban, but it is a free first layer.

Inspect, edit, and undo

sudo ufw status numbered     # list rules with index numbers
sudo ufw delete 3            # remove rule #3
sudo ufw reload              # reapply after edits

Because rules are numbered, you can remove a mistake without flushing everything. Keep the list short — a firewall you understand at a glance is one you will actually maintain.

A sensible default set

For a typical web VPS, the whole policy is four ideas: deny incoming by default, allow and rate-limit SSH, allow 80/443, and keep every datastore bound to localhost. That is enough to take a box from "exposed by default" to "exposes only what you chose," which is the entire point.

Closing note

A firewall is layer one, not the whole story — combine it with SSH keys, prompt updates, and least-privilege services. If you would rather start from a platform that already takes isolation seriously, overnight.host runs full-root KVM VPS in multiple regions (EU and US), where each tenant is genuinely isolated and the specs are honest — you still own your firewall, we just give you a clean, well-fenced box to run it on.

Choosing a VPS region: latency, data residency, and where your users actually are

overnight.host — Tue, 23 Jun 2026 07:18:49 +0000

Picking a data-centre region feels like a minor checkbox at checkout, but it quietly shapes how fast your service feels and which rules apply to your data. Here is how to choose it deliberately instead of accepting whatever the default happens to be.

1. Put the server near your users, not near you

Network latency is dominated by physical distance. Light in fibre is fast but not instant, and every router adds a little more. As a rough mental model, a round trip across an ocean is ~80-150 ms, within a continent ~10-40 ms, and within a metro ~1-5 ms. If your developer machine is in Berlin but your players are in Texas, hosting in Germany "because that is where you are" can add 100+ ms to every interaction for them.

Test it before you commit:

# round-trip time to a host in a candidate region
ping -c 5 some-host-in-that-region.example

2. Match the latency budget to the use case

Not everything needs to be twitch-fast:

Competitive game servers, voice, real-time apps: latency is everything. Pick the region closest to the bulk of your players, even if it splits your audience across two servers.
Web apps and dashboards: users tolerate more, and a CDN in front hides a lot. Origin region still matters for dynamic, database-backed requests.
Batch jobs, scrapers, build runners, bots: region barely matters for throughput — put them wherever is cheapest or most convenient, with one exception below.

3. Data residency and compliance

Where your data physically sits can carry legal weight. If you handle personal data of EU residents, keeping that data in an EU region is the simplest way to stay on the right side of GDPR expectations and to answer the "where is our data?" question honestly. US and other jurisdictions have their own rules. The point is to choose region as a deliberate compliance decision, not an afterthought — and to be honest with your own users about where their data lives rather than overclaiming.

4. A CDN changes the math for static content

If most of what you serve is cacheable — images, CSS, JS, static pages — a CDN like Cloudflare serves it from an edge near each visitor regardless of where your origin lives. In that case the origin region mostly affects cache misses and dynamic requests. If your traffic is heavily dynamic or database-driven, the origin region matters a lot more, because every request goes the full distance.

5. When to go multi-region

Reach for multiple regions when you genuinely have two centres of gravity (say, a European and a North American audience) and latency to one of them is hurting. Multi-region adds real operational complexity — data sync, failover, more moving parts — so do it because the numbers demand it, not because it sounds impressive. Many projects are better served by one well-chosen region plus a CDN.

The short version

Ping a few candidates, put the origin near the users who feel latency most, keep regulated data in an appropriate jurisdiction, and let a CDN cover the static stuff. "Closest to me" is rarely the right default.

overnight.host runs VPS and game servers in multiple regions — EU and US today, with more coming — so you can pick the one nearest your users rather than nearest us. Honest specs, full root, cancel-anytime billing, in your region.

How much RAM does your game server actually need? A practical sizing guide

overnight.host — Tue, 23 Jun 2026 07:17:43 +0000

"How much RAM do I need?" is the first question for anyone spinning up a game server — and most answers online are either marketing ("buy more!") or pure guesswork. Here is a practical, honest way to size it, based on what actually consumes memory rather than what a sales page wants you to buy.

What actually uses memory

Four things, roughly:

The base server process. Every game server has a fixed footprint just to boot and idle with nobody connected.
The world or map. Larger, older, more-explored worlds hold more in memory. A Minecraft world that has been mined across thousands of chunks costs far more than a fresh one.
Players and entities. Each connected player loads the area around them; mobs, items, vehicles and physics objects all add up.
Mods and plugins. This is the big multiplier. A vanilla server and a heavily-modded one of the same game can differ by an order of magnitude.

Rule-of-thumb baselines

These are sane starting points for a small-to-medium community, not hard limits:

Minecraft (Vanilla / Paper): 2-4 GB for up to ~10-20 players. Paper is more memory-efficient than vanilla at scale.
Minecraft (modded — Forge / Fabric, big modpacks): 6-10 GB is common; some kitchen-sink packs want more. The modpack, not the player count, drives this.
Rust: 8 GB minimum for a real map, often more on larger worlds — Rust is genuinely memory-hungry.
Counter-Strike 2 / Source-engine games: 1-2 GB is usually plenty; these are CPU- and tick-rate-bound more than RAM-bound.
ARK: 8-16 GB depending on map and mods; another hungry one.

Why "just buy 16 GB" is usually the wrong instinct

Two reasons. First, Java games like Minecraft do not get faster with a huge heap — an oversized -Xmx can make garbage-collection pauses worse, not better. Sizing the heap correctly (and using sane GC flags) beats brute force. Second, you pay for memory you never touch. It is cheaper and just as reliable to start at a sensible tier and move up if real usage demands it.

Measure instead of guess

Once your server is running under a realistic load, look at actual usage:

# live view of memory per process
htop

# quick total snapshot
free -h

Watch it with the player count you actually expect on a busy evening, not an empty server at 3am. If you sit comfortably under your allocation with headroom to spare, you are sized right. If you are pinned near the ceiling and seeing lag spikes, step up one tier.

One honest caveat about "cheap" RAM

A very cheap "game server" or "VPS" is sometimes an oversold shared container where the advertised RAM is burstable, not guaranteed — your process can be starved when a neighbour spikes. On real KVM virtualisation you get your own kernel and dedicated (not burstable) RAM, which is what a game server actually needs to stay stable under load. If a host will not say whether RAM is dedicated, ask before you buy.

Want to skip the mental math? We built a free game server RAM calculator that sizes Minecraft, Rust, ARK and more from player count and mods — no signup. If you would rather have it managed, overnight.host runs game servers on dedicated bare metal with full file access and daily backups, in your region.

How to monitor your VPS on a budget — uptime, resources and alerts

overnight.host — Mon, 22 Jun 2026 02:40:56 +0000

The cheapest way to find out your server is down is for a user to tell you. Don't be that operator. Monitoring a VPS well costs nothing but an afternoon, and it turns "why didn't anyone notice for six hours" into a push notification before most people refresh the page. Here's a practical, free stack.

Three things worth watching

Is it up? Reachability from outside your own network.
Is it healthy? CPU, RAM, disk — the slow leaks that take a box down at 4 a.m.
Did something break? Failed services, full disks, errors in logs.

You can cover all three without paying for an enterprise APM.

1. External uptime checks

The single most important monitor lives off your server, because a check running on a dead box can't alert you. Free options like Uptime Kuma (self-hosted on a second machine) or a hosted free tier ping your URL every minute and notify you on failure.

If you self-host Uptime Kuma, run it somewhere other than the server it watches — a second cheap VPS in a different region, or a Raspberry Pi at home. Point it at your real user-facing URL, not just the IP, so you catch TLS and DNS failures too.

A nice habit: publish your uptime on a public status page. It keeps you honest and answers the "is it just me?" question without a support ticket.

2. Resource monitoring

For a single box, htop and df -h over SSH go a long way, but you want history, not just a snapshot. A lightweight, genuinely free option is netdata:

wget -qO- https://my-netdata.io/kickstart.sh | sh

It gives you per-second CPU, memory, disk I/O, and network graphs in a local web UI with essentially no configuration. Bind it to localhost and reach it through an SSH tunnel rather than exposing the dashboard to the internet:

ssh -L 19999:localhost:19999 root@your-server

Then open http://localhost:19999.

3. Service and disk alerts

The two failures that bite small servers most often are a service that died silently and a disk that filled up. Catch both with a tiny cron script:

#!/usr/bin/env bash
# /usr/local/bin/healthcheck.sh
DISK=$(df / | awk 'END{print +$5}')
if [ "$DISK" -gt 85 ]; then
  echo "Disk at ${DISK}% on $(hostname)" | mail -s "DISK WARNING" you@example.com
fi
systemctl is-active --quiet nginx || \
  echo "nginx down on $(hostname)" | mail -s "SERVICE DOWN" you@example.com

chmod +x /usr/local/bin/healthcheck.sh
# run every 5 minutes
echo "*/5 * * * * root /usr/local/bin/healthcheck.sh" | sudo tee /etc/cron.d/healthcheck

No mail server set up? Pipe the alert to a push service like ntfy instead — a one-line curl to a private topic lands on your phone.

Don't over-alert

The fastest way to start ignoring alerts is to get fifty a day. Alert on things that need a human: down, nearly-full, service crashed. Let graphs handle the rest — you look at those when you're investigating, not when you're asleep.

Closing note

Good monitoring is mostly about putting the check in the right place (outside the box) and not crying wolf. If you'd rather not babysit it, every plan at overnight.host backs a 99.9% uptime SLA with live, public numbers you can check yourself — same philosophy, just one less thing for you to run, in whichever region you choose.

Reverse proxy on a VPS with Caddy — automatic HTTPS in minutes

overnight.host — Mon, 22 Jun 2026 02:40:25 +0000

If you run more than one web app on a single VPS — a site on port 3000, an API on 8080, a dashboard on 9000 — you don't want visitors typing port numbers. You want app.example.com and api.example.com to just work, over HTTPS, without you hand-rolling TLS certificates. That's what a reverse proxy does, and Caddy makes it about as painless as it gets.

Why Caddy

Nginx and Traefik are both excellent. Caddy earns its place because of one feature: it provisions and renews TLS certificates from Let's Encrypt automatically, with zero config beyond naming your domain. No certbot cron job, no renewal surprises at 2 a.m. For a small operator that one thing removes a whole category of outages.

Prerequisites

A VPS with root (any KVM box with full root will do — distro doesn't much matter).
A domain with DNS pointing at your server's public IP. If your VPS uses NAT IPv4, make sure the HTTP/HTTPS ports you need are actually forwarded to it — check with your host before you debug for an hour.
Ports 80 and 443 open in your firewall.

Install

On Debian or Ubuntu:

sudo apt install -y debian-keyring debian-archive-keyring apt-transport-https curl
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | sudo gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' | sudo tee /etc/apt/sources.list.d/caddy-stable.list
sudo apt update && sudo apt install caddy

Caddy installs as a systemd service and starts immediately.

The Caddyfile

The entire config for proxying two apps lives in /etc/caddy/Caddyfile:

app.example.com {
    reverse_proxy localhost:3000
}

api.example.com {
    reverse_proxy localhost:8080
}

Reload it:

sudo systemctl reload caddy

That's the whole thing. The first time a request hits app.example.com, Caddy fetches a certificate, serves it over HTTPS, and redirects plain HTTP to HTTPS for you. No certbot, no renewal timer.

Useful extras

Gzip/zstd compression and a security header, added inline:

app.example.com {
    encode zstd gzip
    header Strict-Transport-Security "max-age=31536000;"
    reverse_proxy localhost:3000
}

Serve static files and proxy an API under one host:

example.com {
    root * /var/www/site
    file_server
    handle /api/* {
        reverse_proxy localhost:8080
    }
}

A couple of gotchas

DNS first. Caddy can't get a certificate for a name that doesn't resolve to your box yet. Let DNS propagate before you reload.
Rate limits. Let's Encrypt limits how many certs you can request per week. While testing, point Caddy at the staging CA so you don't burn your quota.
Logs. journalctl -u caddy -f shows you exactly what it's doing during the certificate dance — read it the first time, it's reassuring.

Closing note

Caddy turns "I have three things running on one box" into three clean HTTPS hostnames in about ten minutes. Any full-root KVM VPS handles it comfortably — we run a small one for exactly this at overnight.host, in whichever region you pick, with NAT-IPv4 port forwarding disclosed up front so the DNS step doesn't surprise you.

Docker on a VPS - a beginner's guide to your first container

overnight.host — Sun, 21 Jun 2026 07:08:14 +0000

Docker has a reputation for being either magic or a headache, and the truth is it's mostly neither once you've run a couple of containers yourself. If you have a KVM VPS with full root, you can go from a blank box to a running, restart-on-reboot app in about ten minutes. Here's the honest, no-magic path.

Why Docker on a VPS

A container bundles your app and everything it needs into one image, so "works on my machine" becomes "works on the server too." You also get clean isolation (one app's mess doesn't touch another's), easy upgrades (pull a new image, recreate the container), and trivial teardown. The one real requirement: a KVM VPS, not an oversold container-on-a-container. You need your own kernel to run Docker properly — if a host doesn't say KVM anywhere, ask before you buy.

1. Install Docker

The official convenience script works across Debian, Ubuntu, and the RHEL family:

curl -fsSL https://get.docker.com | sudo sh
sudo systemctl enable --now docker
docker --version

Add your user to the docker group so you don't have to sudo every command (log out and back in afterward):

sudo usermod -aG docker $USER

2. Run your first container

Prove it works with something disposable:

docker run --rm hello-world

Now run something real — a web server:

docker run -d --name web -p 80:80 --restart unless-stopped nginx

That's a live nginx on port 80. The flags matter: -d runs it in the background, --restart unless-stopped brings it back after a reboot, and -p 80:80 maps the host port to the container.

3. Use Compose for anything with more than one piece

Most real apps are an app plus a database. docker compose (built into modern Docker) describes the whole stack in one file. Create docker-compose.yml:

services:
  app:
    image: ghost:5
    restart: unless-stopped
    ports:
      - "8080:2368"
    environment:
      database__client: mysql
      database__connection__host: db
      database__connection__user: ghost
      database__connection__password: changeme
      database__connection__database: ghost
    depends_on: [db]
  db:
    image: mysql:8
    restart: unless-stopped
    environment:
      MYSQL_ROOT_PASSWORD: changeme
      MYSQL_DATABASE: ghost
      MYSQL_USER: ghost
      MYSQL_PASSWORD: changeme
    volumes:
      - dbdata:/var/lib/mysql
volumes:
  dbdata:

Then:

docker compose up -d

Two containers, networked together, data persisted in a named volume that survives a compose down.

4. The habits that keep it healthy

Persist data in volumes, never inside the container — containers are disposable, volumes are not.
Don't publish database ports (3306, 5432) to the public internet; let containers reach each other over the internal Docker network instead.
Pin image versions (mysql:8, not mysql:latest) so an upgrade is a decision, not a surprise.
Put a reverse proxy in front (Caddy or nginx) for TLS, instead of exposing app ports directly.

5. Updating and cleaning up

docker compose pull && docker compose up -d   # upgrade in place
docker system prune -f                         # reclaim space from old images

Where to run it

Docker doesn't care which region your server is in — the same image runs identically in the EU or the US. If you need a box to try this on, overnight.host offers KVM VPS with full root access and honest specs (real KVM, SSD, NAT IPv4 disclosed before checkout), hosted in your region. Spin one up, run the hello-world above, and you'll have demystified Docker by lunch.

How to set up automated, off-site backups for your VPS with restic

overnight.host — Sun, 21 Jun 2026 07:08:12 +0000

A backup that lives on the same machine as your data isn't a backup — it's a copy waiting to disappear with the disk. If you run anything on a VPS that you'd be unhappy to lose (a database, a game world, a self-hosted app), you want backups that run on a schedule, leave the server, and can actually be restored. Here's a clean, honest setup using restic, which is free, open-source, encrypted by default, and deduplicates so repeated backups stay small.

1. Install restic

On Debian/Ubuntu:

sudo apt update && sudo apt install -y restic

On AlmaLinux/Rocky:

sudo dnf install -y epel-release && sudo dnf install -y restic

2. Pick an off-site destination

The whole point is "not on this server." Good options: an S3-compatible object store, a second VPS in another region, or an SFTP target. restic encrypts everything client-side before it leaves the box, so the destination never sees your plaintext.

export RESTIC_REPOSITORY="sftp:backup@backup-host:/srv/restic/myvps"
export RESTIC_PASSWORD="a-long-random-passphrase-you-store-safely"
restic init

Keep that passphrase somewhere safe and separate. Without it, the repository is unrecoverable — which is exactly what protects you if the backup host is ever compromised.

3. Back up the things that matter

Don't back up the whole root filesystem — you'll just restore the OS. Back up your data:

restic backup /var/lib/mysql /var/www /etc /home --exclude-caches

For databases, dump first so you get a consistent snapshot rather than copying live files:

mysqldump --single-transaction --all-databases > /root/db-$(date +%F).sql
restic backup /root/db-*.sql

4. Automate it with a timer

Drop this into /usr/local/sbin/backup.sh, make it executable, and let cron run it nightly:

#!/bin/bash
set -euo pipefail
export RESTIC_REPOSITORY="sftp:backup@backup-host:/srv/restic/myvps"
export RESTIC_PASSWORD_FILE="/root/.restic-pass"
mysqldump --single-transaction --all-databases > /root/db.sql
restic backup /var/www /etc /root/db.sql --exclude-caches
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

chmod 700 /usr/local/sbin/backup.sh
echo "15 3 * * * root /usr/local/sbin/backup.sh >> /var/log/backup.log 2>&1" | sudo tee /etc/cron.d/restic-backup

The forget --prune line is the part people skip — it keeps a sensible retention window so the repository doesn't grow forever.

5. Test the restore (this is the real step)

An untested backup is a hope, not a plan. Once a month, prove it works:

restic snapshots
restic restore latest --target /tmp/restore-test --include /etc

If the files come back, you have a backup. If they don't, you found out on a Tuesday instead of during a disaster.

A note on where this runs

restic is region-agnostic — it works the same whether your VPS is in the EU or the US, and the encrypted-before-it-leaves design means you stay in control of your data wherever the backup target lives. If you're spinning up a box for this, overnight.host runs KVM VPS with full root and honest specs (SSD, NAT IPv4 disclosed up front), hosted in your region — so you can point your off-site backups at a second region without overthinking it.

Migrating a website to a new host with near-zero downtime

overnight.host — Sat, 20 Jun 2026 18:03:11 +0000

The scary part of moving hosts is the gap where the site is half here and half there. Sequence it right and visitors never notice.

1. Build the new home first, behind the scenes

Set everything up on the new server while the old one keeps serving. Copy the files and the database, get the app running, and test it by hitting the new IP directly (a hosts-file entry on your laptop pointing the domain at the new IP lets you browse the real site there before anyone else does).

2. Lower your DNS TTL ahead of time

A day before the move, drop the TTL on the relevant records to 300 seconds. Now when you flip, caches expire in minutes instead of a day or two. Do this early, because the old long TTL has to expire first.

3. Freeze, sync the delta, flip

Pick a quiet window. Put the old site in read-only or maintenance mode briefly, sync the last database changes and any new uploads to the new box, then change the DNS A record to the new IP. Because the TTL is low, resolvers pick it up fast.

4. Both servers serve during the overlap

For a short while, some visitors still hit the old IP and some hit the new one. This is why you went read-only for the cutover: so no writes land on the old box that the new one misses. Once traffic has clearly moved (check your new server's access logs), you can lift maintenance mode on the new host.

5. Re-issue TLS and confirm

Make sure the certificate on the new host covers the domain, then walk the site: forms, logins, checkout, the lot. Leave the old server up for a few days as a fallback before you tear it down.

The one that bites people

Email and DNS often live with the old host. Before you cancel anything, move your MX records and any other records, not just the A record, or you will silently lose mail.

overnight.host does free migrations as part of onboarding for exactly this reason: the sequencing is routine for us and nerve-wracking to do alone for the first time.

Self-hosting n8n or Activepieces vs letting someone manage it

overnight.host — Sat, 20 Jun 2026 18:02:25 +0000

Open-source workflow automation (n8n, Activepieces) is the privacy-friendly answer to Zapier and Make. The engine is free. The question is who runs it.

What self-hosting actually involves

Spinning up the container is the easy part. Keeping it healthy is the job:

A database (Postgres) and Redis, backed up, with backups you have actually restored once.
TLS, a reverse proxy, and a domain.
Updates, which sometimes include breaking schema migrations you have to read the notes for.
Monitoring so you find out a flow stopped firing before your customer does.
Secrets and connection tokens stored encrypted, not in plaintext env files.

If you enjoy that and have the time, self-hosting is great and you keep total control.

When managed makes sense

If the automations are running your business rather than your hobby, the math changes. Managed means someone else owns the database backups, the updates, the TLS renewals and the monitoring, and you get an isolated instance you just build on. You still own the workflows, because the engine is open source (MIT) and your flows export cleanly. No lock-in, less plumbing.

The honest middle

A good test: if your automations going dark for a day would cost you real money, pay someone to run them. If it would just be annoying, self-host and learn a lot.

Region matters for compliance

Where the instance and its backups physically live is a real decision if you handle personal data. Pick a host that lets you choose the region at checkout and will sign a data processing agreement for the EU, rather than one that is vague about where the box is.

overnight.host runs managed open-source automation on isolated per-customer instances, in the region you pick (EU or US), with a live demo panel you can poke at before you commit. The engine stays open source, so your workflows are always yours.

How to point a domain at your VPS — DNS, A records and TLS

overnight.host — Sat, 20 Jun 2026 18:02:24 +0000

You have a VPS with a public IP and a domain sitting at a registrar. Connecting the two trips up more people than it should. Here is the whole path.

1. The A record is the core of it

An A record maps a name to an IPv4 address. At your DNS provider, add:

Type  Name   Value
A     @      203.0.113.10
A     www    203.0.113.10

@ is the bare domain (example.com), www is the subdomain. If you have IPv6, add AAAA records with the same names pointing at your v6 address.

2. Understand TTL and propagation

TTL is how long resolvers cache the record. Set it low (300 seconds) before a planned change so the switch is fast, then raise it again afterwards. "Propagation" is just caches expiring around the world; there is nothing to speed up except waiting out the TTL.

3. Check it from the outside, not your browser

dig +short example.com
dig +short www.example.com

Your browser caches and your OS caches, so trust dig against a public resolver over a page reload.

4. Add TLS once DNS resolves

Certbot with the HTTP challenge needs the domain to already point at the box and port 80 reachable:

apt install certbot python3-certbot-nginx
certbot --nginx -d example.com -d www.example.com

If you are behind a CDN or want wildcards, use the DNS-01 challenge instead, which proves control through a TXT record rather than a live web server.

5. A note on NAT-IPv4 hosts

On budget hosts your VPS may share an IPv4 and get specific forwarded ports rather than the whole IP. That is fine for most workloads, but it changes how you point a domain: you map the name to the shared IP and reach your service on its forwarded port, or you put a reverse proxy in front. Always check whether your plan gives you a dedicated IP or a NAT one before you design around it.

At overnight.host we are upfront about which plans are NAT-IPv4 and which give a dedicated IP, because finding out after you have wired DNS is nobody's idea of fun.

Securing a fresh VPS — the 15-minute checklist

overnight.host — Sat, 20 Jun 2026 18:00:21 +0000

You just spun up a VPS. Before you put anything real on it, spend fifteen minutes locking it down. Here is the order that catches the most risk for the least effort.

1. Create a non-root user

Working as root all day means one fat-fingered command can wipe the box. Make a user and give it sudo:

adduser deploy
usermod -aG sudo deploy

2. Switch to SSH keys, then turn off password login

Passwords get brute-forced around the clock. Copy your key up, confirm you can log in with it, then in /etc/ssh/sshd_config set PasswordAuthentication no and PermitRootLogin prohibit-password, and reload sshd. Keep a second terminal open until you have confirmed the new login works, so you never lock yourself out.

3. Turn on a firewall with a default-deny stance

Only open what you actually serve:

ufw default deny incoming
ufw default allow outgoing
ufw allow OpenSSH
ufw enable

Add ufw allow 80,443/tcp when you put a web server on it. The principle is the same one we run at the host level: deny by default, allow on purpose.

4. Add fail2ban

It watches your auth log and bans IPs that hammer SSH. apt install fail2ban and the default jail is already sensible.

5. Patch, then enable unattended security updates

apt update && apt upgrade -y
apt install unattended-upgrades
dpkg-reconfigure -plow unattended-upgrades

6. Know where your backups are

A server you cannot restore is a server you do not really have. Snapshot before big changes, and keep at least one copy off the box.

That is the 15-minute baseline. None of it is exotic, and skipping it is how most small servers get owned.

We run overnight.host on rented bare metal across EU and US regions, with a default-deny firewall and key-based access as the standard, not an upsell. If you want a VPS that ships locked down, that is the idea.