DEV Community: overnight.host

Self-hosting WordPress on a VPS: Docker Compose, HTTPS, and the redirect loop nobody explains

overnight.host — Wed, 16 Sep 2026 15:15:08 +0000

WordPress on a VPS is not hard to start. It is hard to finish: the database credentials, the volume that has to survive an upgrade, and the one setting that sends wp-admin into an endless redirect the moment a reverse proxy sits in front of it.

The compose file

Three services: WordPress, MariaDB, and nothing else. Pin both image tags — the comments below say where to check the current release — so an upgrade is a line you change on purpose, not something that lands on a restart.

services:
  db:
    image: mariadb:11  # check hub.docker.com/_/mariadb/tags for the current point release
    restart: unless-stopped
    environment:
      - MARIADB_ROOT_PASSWORD=${DB_ROOT_PASSWORD}
      - MARIADB_DATABASE=wordpress
      - MARIADB_USER=wordpress
      - MARIADB_PASSWORD=${DB_PASSWORD}
    volumes:
      - db_data:/var/lib/mysql

  wordpress:
    image: wordpress:6-apache  # check hub.docker.com/_/wordpress/tags for the current point release
    restart: unless-stopped
    depends_on: [db]
    environment:
      WORDPRESS_DB_HOST: db
      WORDPRESS_DB_NAME: wordpress
      WORDPRESS_DB_USER: wordpress
      WORDPRESS_DB_PASSWORD: ${DB_PASSWORD}
      WORDPRESS_CONFIG_EXTRA: |
        if (isset($$_SERVER['HTTP_X_FORWARDED_PROTO']) && $$_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') {
            $$_SERVER['HTTPS'] = 'on';
        }
        define('FORCE_SSL_ADMIN', true);
    volumes:
      - wp_content:/var/www/html/wp-content
      - ./uploads.ini:/usr/local/etc/php/conf.d/uploads.ini:ro
    ports:
      - "127.0.0.1:8080:80"

volumes:
  db_data:
  wp_content:

The credentials live in a .env file next to the compose file, never inline in the YAML:

printf 'DB_ROOT_PASSWORD=%s\nDB_PASSWORD=%s\n' "$(openssl rand -hex 24)" "$(openssl rand -hex 24)" > .env
chmod 600 .env

Notice the volume only covers /var/www/html/wp-content, not the whole install. That directory is themes, plugins and uploads — the parts that are actually yours. The rest of WordPress core lives inside the image, which is exactly what makes bumping the tag later a clean operation instead of a merge conflict with your own files.

HTTPS behind Caddy, and the redirect loop

blog.example.com {
    reverse_proxy 127.0.0.1:8080
}

That's the whole file — Caddy requests and renews the certificate the moment it starts, provided the DNS A record already points at the machine. Caddy also forwards the original request scheme as the X-Forwarded-Proto header on every hop, which is where the redirect loop comes from.

WordPress talks to the wordpress container over plain HTTP inside the Docker network — TLS ended at Caddy, three hops back. Left alone, WordPress sees HTTP_X_FORWARDED_PROTO=https from the browser's real request but still thinks the connection to itself is http, and FORCE_SSL_ADMIN — which you want, so wp-admin never runs unencrypted — keeps redirecting a page it believes is already loading over HTTP to https, forever. The three lines in WORDPRESS_CONFIG_EXTRA above are the fix: they read the header Caddy already sends and set PHP's own $_SERVER['HTTPS'] before WordPress makes that decision, so FORCE_SSL_ADMIN sees a request that is genuinely HTTPS and stops looping. Skip those lines and the symptom is specific: wp-admin loads fine over plain HTTP direct to the container, then loops the instant Caddy is in front of it.

Notice every $_SERVER above is written as $$_SERVER in the compose file. That's not a typo: Compose does its own $VAR substitution over every string in docker-compose.yml, block scalars included, before the file is even parsed as YAML, and $_SERVER looks exactly like a reference to an environment variable named _SERVER. Leave the dollar signs single and Compose quietly substitutes an empty string for the (unset) _SERVER variable, and the broken PHP that results lands straight in wp-config.php — the site fatals instead of just failing to fix the redirect loop. Doubling the $ is how you tell Compose to leave it alone and pass a literal $ through to PHP.

The upload limit nobody remembers

WordPress's own media-upload cap is set by PHP, not by anything in wp-admin. The official image is built on php:apache, which reads every .ini file dropped into /usr/local/etc/php/conf.d/, so a small file mounted read-only does the job without touching the image:

file_uploads = On
memory_limit = 256M
upload_max_filesize = 64M
post_max_size = 64M
max_execution_time = 300

post_max_size has to be equal to or larger than upload_max_filesize, or the smaller one silently wins and a "large" theme zip or plugin archive fails with no useful error. Caddy itself doesn't cap request body size by default the way some reverse proxies do, so with the Caddyfile above there's nothing on Caddy's side to raise — but if you ever add a request_body { max_size ... } directive to that block, that becomes a second ceiling above post_max_size, and the smallest number in the chain still wins.

Read this before you buy: the NAT catch for 443

A NAT IPv4 VPS gives you a handful of forwarded ports; whether 443 is among them depends on the plan, so check before you point DNS at the box — and whichever ports you get are forwarded to the machine, not to any one container. If this box only ever runs one site, that is a non-issue: Caddy binds 443, WordPress sits behind it, done. The catch shows up the moment you want a second HTTPS site or app on the same VPS — you cannot also bind a second process straight to 443, because the port only exists once at the network layer.

The fix is the one Caddy already gives you for free: run a single Caddy instance as the only thing bound to 443, and route by hostname. Add a second block to the same Caddyfile for a second site, pointed at a different 127.0.0.1:<port>, and Caddy picks the right backend from the Host header before anything reaches either app. What you cannot do is run WordPress's own container with a direct 443:443 port mapping once anything else needs that same port too.

If you specifically need a standalone IPv4 address with 443 all to itself, that exists but is arranged by e-mail, not something you self-service from the panel. Check what your plan forwards before you commit a domain to it — NAT IPv4, ports and forwarding and NAT IPv4 vs a dedicated IP cover the mechanics in more depth than a WordPress guide needs to.

Security basics that matter more than any plugin

None of this is a plugin problem, and installing one rarely fixes it:

Few plugins. Every plugin is code you didn't audit, running with the same access as WordPress core. A site with five well-maintained plugins is safer than one with thirty, independent of what any of them individually claims to do for security.
Automatic minor updates, on. WordPress applies minor and security releases automatically by default; don't turn that off. If you want it explicit in the config anyway, add define('WP_AUTO_UPDATE_CORE', 'minor'); to WORDPRESS_CONFIG_EXTRA alongside the two lines above.
A real admin username, not admin. The install wizard already asks you to pick one — use it. admin is the first guess in every credential-stuffing list on the internet, and a unique username removes half of a brute-force attempt before it starts.
Limit repeated login attempts. This can be a plugin, but it doesn't have to be: fail2ban watching your access log for repeated hits on wp-login.php does the same job at the network layer, without adding another piece of PHP to the site itself.

Backups: the volume and the database

Two things, and the database changes constantly so it needs its own step:

docker compose exec db sh -c 'mariadb-dump -u root -p"$MARIADB_ROOT_PASSWORD" wordpress' > "wordpress-$(date +%F).sql"

That reads the root password straight out of the db container's own environment, so nothing sensitive touches your shell history. For the volume — themes, plugins, uploads, everything that isn't the database:

docker run --rm -v wordpress_wp_content:/data -v "$(pwd)":/backup alpine:3.20 \
  tar czf "/backup/wp-content-$(date +%F).tar.gz" -C /data .

Adjust the volume name to whatever docker compose config --volumes actually prints for your project — Compose prefixes it with the project directory name by default. Copy both files off the VPS entirely; a dump sitting next to the instance it came from is not a backup, it's a file. back up your VPS covers what off-machine actually means in practice.

Updates: bump the tag, let WordPress do the rest

docker compose pull
docker compose up -d

Take the mariadb-dump above immediately before you do this, not after. WordPress runs its own database upgrade automatically the first time an admin loads a page on the new version — you don't run a separate migration command — but that upgrade is a one-way trip. Read the release notes for the version you're jumping to before you bump the tag, especially across a major version.

Sizing

WordPress plus MariaDB plus Caddy is a light stack for a small site with a caching plugin doing its job: 1 GiB of RAM is a workable floor, and disk is mostly the media library rather than the application itself.

The number changes once the site does more than serve pages. WooCommerce adds a real amount of database weight — orders, sessions, product variations — and a page builder like Elementor or Divi runs noticeably heavier PHP per request while you're editing, even if the public-facing page stays fast. 2 GiB is the realistic floor once either shows up, and it's worth moving before the site is slow rather than after.

On overnight.host

Full disclosure: this is what we sell. If you want the site without the sysadmin, the managed WordPress container comes with its own hostname and certificate.

One-click apps — EUR 4 to EUR 12 a month, hosted in Germany (EU). Eight apps: n8n, Uptime Kuma, Vaultwarden, Gitea, Nextcloud, Ghost, Managed WordPress, Private AI Chat. Each customer gets an isolated Docker network and volume, plus a hostname under apps.overnight.host on a real wildcard certificate. Memory and CPU are capped per plan by the container runtime.

You order in the shop, pay by card (Stripe) or SEPA bank transfer, and your login details are e-mailed to you once the service is set up. Support is e-mail, run by one person, with no guaranteed response time. All prices are final totals under the German small-business rule (§19 UStG); no VAT is added or shown.

Order managed-wordpress → · One-click apps overview

FAQ

Why does wp-admin keep redirecting in a loop behind Caddy?

WordPress can see the request was HTTPS from the browser, but doesn't know its own connection to itself counts, so FORCE_SSL_ADMIN keeps trying to force a scheme it already thinks it's not using. Reading HTTP_X_FORWARDED_PROTO and setting $_SERVER['HTTPS'] before that check runs, as shown above, is what breaks the loop.

Can I run more than one HTTPS site on the same NAT IPv4 VPS?

Yes, but only through one process bound to 443. Put Caddy in front of everything and give it one block per hostname; each site's own container stays on a private port that only Caddy talks to. What doesn't work is two containers each trying to bind 443 directly.

What actually happens if I skip the uploads.ini?

Media uploads and plugin or theme installs fail past PHP's default limit — usually a fairly small number — with an error that looks like the file is corrupt rather than "too big." It's one of the more common "WordPress is broken" reports that's actually a PHP setting no one raised.

I already back up the wp-content volume — do I still need a separate database dump?

Yes. The volume has your files; the database has your posts, settings, and everything WooCommerce or any plugin stores as rows rather than files. A restore with one and not the other gets you a site with all its files and none of its content, or the reverse.

Is a managed WordPress container different from self-hosting?

Same application underneath. The difference is who holds the shell: a managed container gives you the site, a hostname and a certificate, and you don't get to edit uploads.ini or SSH in to run docker compose pull yourself. If you want that level of control, put it on a VPS instead.

Originally published at overnight.host. We run a small, honest hosting company on dedicated bare metal: Linux & Windows VPS, game servers, web hosting. Live status at up.overnight.host.

Docker Compose on a 1 GiB VPS: what actually fits, and how to keep it up

overnight.host — Wed, 16 Sep 2026 07:15:07 +0000

Docker itself is not the problem on a 1 GiB box — the daemon idles under 50 MB. The problem is that Compose will happily start five containers with no memory limits at all, and the kernel's OOM killer does not ask which one you meant to keep.

Install Docker Engine, not docker.io

Ubuntu's own repository ships an old, renamed build called docker.io. Skip it and add Docker's official apt repository instead, so you get current releases and the docker compose plugin as a first-class package, not the separate Python tool it used to be. The full steps also live in Docker's own Ubuntu install guide:

sudo apt update
sudo apt install -y ca-certificates curl
sudo install -m 0755 -d /etc/apt/keyrings
sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc
sudo chmod a+r /etc/apt/keyrings/docker.asc

echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu \
  $(. /etc/os-release && echo "$VERSION_CODENAME") stable" | \
  sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

sudo apt update
sudo apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

Add your user to the docker group so you stop typing sudo in front of every command, then start a new shell for it to take effect:

sudo usermod -aG docker "$USER"
newgrp docker

From here it is docker compose — no hyphen, a subcommand of the docker CLI — not the old standalone docker-compose binary. The compose file syntax is identical either way.

Add a swap file before you add containers

A 1 GiB Starter has exactly 1 GiB of RAM and nothing behind it. Without swap, the moment memory pressure crosses that line, the kernel picks a process to kill — sometimes sshd, not the container you meant to lose. A swap file does not make your workload faster; it turns a hard crash into a slow one you can watch coming with free -h:

sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

Two gigabytes is a reasonable default on a 25 GB disk. Also lower how eagerly the kernel reaches for it — on a server you want swap as an emergency buffer, not an active memory tier:

echo 'vm.swappiness=10' | sudo tee /etc/sysctl.d/99-swappiness.conf
sudo sysctl --system

Read this before you buy: the NAT IPv4 catch

This only matters for containers that need to be reached from outside — a web UI, a webhook, anything with a browser pointed at it. A background worker that only makes outbound calls does not care.

Cheap VPS plans commonly hand you NAT IPv4 — a shared address with a small set of forwarded ports — rather than an address of your own. A reverse proxy that gets a certificate and serves HTTPS needs to own ports 80 and 443 on a public address; a forwarded port like 41022 instead means plain https://app.example.com will not work, because you do not hold 443 on that IP.

Two honest ways through it:

Get a dedicated IPv4. Then 80 and 443 are yours and Caddy below works exactly as written. On our plans that is available on request by e-mail, not as a self-service add-on.
Skip the reverse proxy entirely for anything that does not need a browser hitting it. A sync agent, a backup job, an outbound n8n workflow, a Docker-based CLI tool — none of that needs an inbound port at all.

Read NAT IPv4 vs a dedicated IP and NAT IPv4, ports and forwarding before you order if you are not sure which situation you are in.

Give every service a memory limit

Compose files often show a deploy.resources.limits.memory block, documented in the Compose Specification's deploy section, and leave it at that. On a plain docker compose up, it is silently ignored — deploy is written for Swarm, and outside Swarm mode Compose only honors it when you add the --compatibility flag, which translates it into the same cgroup limit as the older mem_limit property:

docker compose --compatibility up -d

If you would rather not remember a flag on every invocation, use mem_limit directly. It is a legacy top-level property, still fully supported by the compose plugin, and it applies with a plain docker compose up. The Uptime Kuma tag below is an old 1.x release kept only to show the syntax, not a recommendation — check the project's GitHub releases page for whatever is actually current before you copy this in:

services:
  uptime-kuma:
    image: louislam/uptime-kuma:1.23.16
    restart: unless-stopped
    mem_limit: 200m
    memswap_limit: 400m
    volumes:
      - kuma_data:/app/data
    ports:
      - "127.0.0.1:3001:3001"

volumes:
  kuma_data:

mem_limit caps physical memory; memswap_limit caps memory plus swap, and doubling it lets the container spill a little into the swap file instead of getting OOM-killed the instant it touches the ceiling. Set both, on every service, before you decide the box "isn't big enough" — an unbounded container competing with three other unbounded containers is a resource-allocation problem, not a RAM problem.

Log rotation, or the disk fills quietly

Docker's default logging driver, json-file, keeps every line a container has ever printed to stdout, with no size cap out of the box. A chatty service left running for months can grow its log file into gigabytes on a 25 GB disk, and the symptom shows up as "the disk is full" days after the actual cause.

Set a default at the daemon level so nothing you forget to configure per-service falls through:

{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3"
  }
}

Save that as /etc/docker/daemon.json and restart the daemon:

sudo systemctl restart docker

This only applies to containers created after the restart, so recreate anything already running (docker compose up -d --force-recreate) to pick it up. Override it per service in the compose file when a different limit makes sense:

    logging:
      driver: json-file
      options:
        max-size: "10m"
        max-file: "3"

Three files of ten megabytes each caps that service at 30 MB of logs, rotated automatically, forever.

Pin every image tag

latest is not a version, it is a promise that the maintainer will not break anything, and that promise gets broken eventually, usually on a night you were not planning to debug anything. Pin an explicit tag, the same way the Uptime Kuma line above does:

    image: louislam/uptime-kuma:1.23.16

Bump it deliberately with docker compose pull && docker compose up -d after reading what changed, not automatically. For the strongest guarantee that a redeploy pulls the exact same bytes, pin the digest instead of the tag (image: name@sha256:...) — the right trade for anything holding data you care about.

HTTPS with Caddy, for the services that need it

For anything with a web UI you intend to open in a browser, Caddy is the shortest path to real HTTPS, because it requests and renews the certificate on its own — the mechanics are covered in Caddy's automatic HTTPS documentation:

app.example.com {
    reverse_proxy 127.0.0.1:3001
}

That is the whole config for one service; add another block for each additional hostname. Bind the container's own port to 127.0.0.1, as in the Uptime Kuma example above, so the only thing reachable from the internet is Caddy itself, not every container's raw port.

Caddy's own footprint is small — comfortably under 50 MB idle — so it is not what pushes you over 1 GiB; the containers behind it are. Run one Caddy instance and proxy everything through it rather than giving each service its own.

Pruning: the cleanup that isn't automatic

Every docker compose pull and image rebuild leaves old layers behind. On a 25 GB disk that adds up fast. The safe, routine command is:

docker image prune -f

That removes only dangling images — layers with no tag pointing at them anymore — and never touches anything a running or stopped container still references. docker system prune -af --volumes is the aggressive version, and --volumes is the part to be careful with: it deletes any volume not currently attached to a container, including the data volume of anything you stopped but never removed. Run it by hand, read what it lists before confirming, and never put it in an unattended cron job.

What actually fits in 1 GiB, and what does not

With sane limits set, on a 1 GiB Starter:

Fits comfortably. Uptime Kuma monitoring a few dozen endpoints, idling under 100 MB. Vaultwarden, a lean Rust rewrite of the Bitwarden server, idling under 50 MB. A small n8n instance running a handful of workflows without heavy concurrent executions — see self-hosting n8n on a VPS for the full setup and its own memory notes. Any one or two of these together, each with a mem_limit set, leaves real headroom for the OS and Docker itself.

Does not fit, realistically. Nextcloud once you turn on preview generation — the PHP-FPM workers that render thumbnails spike hard under real usage and get OOM-killed on a 1 GiB box regardless of how carefully you tune it; self-hosting Nextcloud properly covers what it actually needs. Gitea plus CI runners — Gitea alone is light, but each CI job the runner picks up spins up its own container with its own memory demand stacked on top of everything already running. Anything built on Elasticsearch — its documented minimum heap alone is larger than this entire machine, before the OS or any other service gets a share.

The pattern across all three: it is not the base application that breaks 1 GiB, it is a specific feature — previews, CI jobs, a search index — that spikes far above idle. Read the feature list with that in mind, not just a "runs on a Raspberry Pi" marketing line.

On overnight.host

Full disclosure: this is what we sell. A 1 GiB Starter runs two or three small, memory-limited containers without drama; move up a tier the moment you want Nextcloud with previews, Gitea plus CI runners, or anything built on Elasticsearch.

Linux KVM VPS — EUR 4.99 to EUR 59.99 a month, on our own single-tenant bare metal in Dallas, TX and Charlotte, NC. Full hardware virtualisation (KVM), your own kernel, full root. Six tiers, vps-starter to vps-ultra. Starter is 1 vCPU, 1 GiB RAM, 25 GB disk.

Order vps-starter → · Linux KVM VPS overview

FAQ

Does deploy.resources.limits.memory actually do anything with plain docker compose up?

No, not by itself. Compose only applies the deploy section's resource limits when you add the --compatibility flag; without it, the block is parsed and silently ignored. Either add that flag to every invocation or use the simpler mem_limit / memswap_limit properties, which apply on a plain docker compose up with no flag required.

Do I actually need swap on a VPS, or is that a laptop thing?

You need it more on a small VPS than on a laptop with 16 GiB to spare. It is not extra performance — it is the difference between a container getting cleanly OOM-killed and logged versus the kernel picking an arbitrary process, possibly sshd, when memory runs out with no buffer at all.

How do I see what is actually using the memory?

docker stats shows live, per-container cgroup memory and CPU usage, which is what your mem_limit values are being checked against. Cross-check the host total with free -h — if docker stats looks fine but free -h shows swap in heavy use, something outside your containers, or a container with no limit set, is the culprit.

Can I run Nextcloud in 1 GiB if I just don't use previews?

You can get it running, but you are fighting the application's own defaults the whole time, and any visit to the Photos or Files app will try to generate a preview unless you disable that server-side too. It is a smaller, more fragile deployment than the guide it deserves; self-hosting Nextcloud properly is written for the tier that actually suits it.

Is a dedicated IPv4 required just to run Docker Compose?

No. Docker and Compose do not care about your networking situation at all. A dedicated IPv4 only becomes relevant the moment a service needs inbound HTTPS on a public hostname and your default NAT IPv4 does not forward 80 and 443 to you — and plenty of useful compose stacks never need that.

Written by the person who runs overnight.host: a small, honest hosting company on dedicated bare metal — Linux VPS, game servers, web hosting. Live status at up.overnight.host.

Originally published at overnight.host — the canonical, kept-current version of this guide.

A self-hosted CI runner on your own VPS: faster builds, and the one rule you must not break

overnight.host — Tue, 15 Sep 2026 15:15:07 +0000

Hosted CI minutes are metered; a small VPS is not. The build cache stays warm, the Docker layers stay pulled, and the machine costs the same whether you push once a week or forty times a day. There is exactly one rule you must not break.

The rule: never on a public repository

A self-hosted runner executes whatever the workflow file says. On a public repository, anyone can open a pull request from a fork — and if your workflow runs on pull_request, their code runs on your machine. GitHub says this in its own documentation and it is not a theoretical risk: it is how self-hosted runners get turned into crypto miners and credential dumps.

Private repositories only, unless you are running ephemeral runners inside disposable infrastructure and you know exactly why that changes the answer. If you need CI on a public repo, use the hosted runners. That is what they are good at.

What to size it at

CI is bursty CPU and steady disk. 2 vCPU and 4 GB handles typical Node, Python and Go builds without drama; Docker image builds and anything that compiles native code will use everything you give it.

Disk is the sleeper. Between the workspace, the Docker layer cache, and the package caches, a busy runner will quietly eat tens of gigabytes. Plan to prune (below), and know how you would grow the disk before you need to — add extra storage to your VPS covers that on our machines.

One pleasant surprise: a runner only makes outbound connections. It polls the CI service for work; nothing connects in. That means NAT IPv4 is completely fine here — no dedicated address, no port forwarding, nothing to configure. It is one of the few server workloads with no networking caveat at all (NAT IPv4 vs a dedicated IP if you want the background).

Step 1: the machine and a non-root user

Deploy an Ubuntu LTS image and do the basics first: connect to your VPS over SSH and secure your VPS. Then make a user for the runner that is not root and not you:

sudo adduser --disabled-password --gecos "" runner

If your jobs need Docker, adding runner to the docker group grants effectively root on the host, because it can mount the host filesystem into a container. That is an acceptable trade on a single-purpose machine that only builds your own private code. It is not acceptable on a machine that does anything else.

Step 2: GitHub Actions runner

Get the download command and registration token from Settings → Actions → Runners → New self-hosted runner on the repository or organisation — the token is short-lived, so generate it when you are ready to use it.

sudo -u runner -i
mkdir actions-runner && cd actions-runner
curl -o actions-runner-linux-x64.tar.gz -L \
  https://github.com/actions/runner/releases/download/v2.322.0/actions-runner-linux-x64-2.322.0.tar.gz
tar xzf actions-runner-linux-x64.tar.gz
./config.sh --url https://github.com/YOURORG/YOURREPO \
            --token YOUR_REGISTRATION_TOKEN \
            --labels self-hosted,linux,x64,vps \
            --unattended

Install it as a service so it survives a reboot. This part runs as root because it writes a systemd unit, but the service itself runs as runner:

exit
cd /home/runner/actions-runner
sudo ./svc.sh install runner
sudo ./svc.sh start

Target it from a workflow with the labels you set:

jobs:
  build:
    runs-on: [self-hosted, linux, vps]

Step 3: make it ephemeral if you can

A long-lived runner accumulates state: leftover files, mutated global config, a node_modules from three branches ago. Worse, one job can leave something behind that the next job picks up.

./config.sh --ephemeral makes the runner take exactly one job and then deregister. Pair it with a supervisor that re-registers a fresh one and you get the isolation of hosted CI with the warmth of your own cache. It is more moving parts; it is also the difference between "the build only fails on the runner" and a machine you trust.

Step 4: GitLab, if that is where you live

Same shape, different words. Install gitlab-runner, then:

sudo gitlab-runner register \
  --non-interactive \
  --url https://gitlab.com/ \
  --token YOUR_RUNNER_TOKEN \
  --executor docker \
  --docker-image alpine:latest

The docker executor is the one you want: each job gets a fresh container, so the isolation problem from step 3 is solved by default. Its cost is that Docker layer caching between jobs needs deliberate configuration rather than happening for free.

Step 5: stop it filling the disk

This is the maintenance that actually matters. A weekly timer is enough:

docker system prune -af --filter "until=168h"
docker volume prune -f

Add a cleanup of the runner's _work directory if your jobs leave large artefacts behind, and put a disk-usage alert somewhere you will see it. A CI runner that is 100% full does not fail loudly — it fails weirdly, halfway through a step, with an error about something unrelated.

Step 6: secrets

The runner holds real credentials in memory while a job runs. Two habits worth having from day one: keep the machine single-purpose, so nothing else on it can read process memory or the workspace, and prefer short-lived tokens (OIDC to your cloud provider) over long-lived keys stored in repository secrets. If a token can only be exchanged for fifteen minutes of access, a compromised job is an incident rather than a catastrophe.

On overnight.host

Full disclosure: this is what we sell. A runner is a steady, boring workload — two cores and a few gigabytes, up all month, which is exactly what a monthly VPS is priced for.

Order vps-starter → · Linux KVM VPS overview

FAQ

Is a self-hosted runner cheaper than hosted minutes?

It stops being metered, which is the point. A machine that costs the same every month is easier to reason about than a minute counter, and the warm cache often makes builds faster on modest hardware than a cold hosted runner on fast hardware. Whether it is cheaper depends entirely on how much you build.

Can I use a self-hosted runner on a public repository?

You should not. A pull request from a fork can run arbitrary code on your machine. Keep self-hosted runners on private repositories.

How much disk does a runner need?

More than you think — the workspace plus the Docker layer cache plus package caches. Start at 40 GB or more for anything that builds containers, and prune on a schedule.

Does a runner need a dedicated IP address?

No. It only makes outbound connections, so NAT IPv4 with no forwarded ports works perfectly.

Should I run one runner or several?

One per concurrent job you want. Two small runners on separate machines beat one large runner for throughput, because CI parallelism is mostly about not queueing.

Written by the person who runs overnight.host: a small, honest hosting company on dedicated bare metal — Linux VPS, game servers, web hosting. Live status at up.overnight.host.

Originally published at overnight.host — the canonical, kept-current version of this guide.

Self-hosting code-server on a VPS: the honest RAM math, Caddy HTTPS, and the Open VSX catch

overnight.host — Tue, 15 Sep 2026 07:15:07 +0000

code-server is Coder's build of VS Code that runs on a server and serves the whole editor to any browser. On a VPS it turns into a personal cloud IDE you can open from a tablet, a work laptop with no admin rights, or a machine you don't trust with your SSH keys — but it is still a process on a small box, and the honest framing matters more than the install command.

What this is actually for, and what it isn't

A browser IDE on a 2 GiB VPS is for editing, running git, and light builds: a script, a static site, a small service you go build or npm run build locally on the box. It is not a replacement for a CI runner or a beefy workstation. The editor itself is lightweight, but the moment you open a real project, language servers and extensions are what eat the RAM, not the VS Code shell around them — a TypeScript server indexing a medium repo, rust-analyzer, or Pylance-equivalents each want their own few hundred megabytes, and they stay resident for as long as the folder is open.

That's the number to plan around, not the idle footprint. code-server itself idles well under 200 MB. Add one active language server and a handful of extensions and a real session settles closer to 700 MB–1 GiB, before the OS and Caddy. 1 GiB works only for light editing — config files, short scripts, no language server doing real indexing. 2 GiB is the realistic floor for a genuine coding session with one language server running. Compile anything non-trivial alongside it, or run a second always-on service on the same box, and that's a reason to size up rather than watch the OOM killer pick a fight with sshd.

Installing code-server

Coder publishes an install script, and the right way to run it is to read it first, not pipe it straight into a shell:

curl -fsSL https://code-server.dev/install.sh -o install-code-server.sh
less install-code-server.sh
sh install-code-server.sh

On Ubuntu the script detects the distribution and installs the .deb package it downloads, the same artifact published on the project's GitHub releases page. If you'd rather skip the script entirely, grab that .deb yourself and install it with apt, which resolves dependencies for you where a bare dpkg -i would not. code-server's release assets carry the version in the filename (code-server_4.92.2_amd64.deb, not a bare code-server_amd64.deb), so there's no unversioned shortcut URL — resolve the current tag first, then build the filename from it:

VERSION=$(curl -fsSL https://api.github.com/repos/coder/code-server/releases/latest | grep -Po '"tag_name": *"v\K[^"]+')
curl -fsSL -o code-server.deb "https://github.com/coder/code-server/releases/download/v${VERSION}/code-server_${VERSION}_amd64.deb"
sudo apt install ./code-server.deb

Either path installs the same package. Check the code-server releases page if you'd rather copy the current filename by hand instead of scripting it.

Running it as yourself, not as root

The package ships a systemd template unit, code-server@.service, meant to run as your normal non-root user — the @ takes the username. Never run an internet-facing editor as root; it has a terminal, and a terminal as root is the whole machine.

sudo systemctl enable --now code-server@$USER
systemctl status code-server@$USER

That starts code-server under your own account, reading its config from your own home directory, and restarts it automatically after a reboot or a crash. sudo journalctl -u code-server@$USER -f shows the live log if something isn't coming up.

The config file: bind-addr, auth, and what `auth: none` really means

First launch writes ~/.config/code-server/config.yaml with a random password already in it. Open it and set it deliberately instead of trusting the generated one blindly:

bind-addr: 127.0.0.1:8080
auth: password
password: <a long, random password, not the generated one if you didn't check it>
cert: false

bind-addr on 127.0.0.1:8080 means code-server only answers on the loopback interface — nothing on the open internet can reach port 8080 directly, only whatever reverse proxy runs on the same machine. Leave cert: false here; Caddy is doing TLS, not code-server itself.

auth: none exists, and it is not automatically wrong — but it is only sane when something else in front of code-server is doing the authenticating, a VPN you connect over first, or basic auth on the proxy in front of it (below). Turn off code-server's own password and put nothing else in its place, and you've published a shell to anyone who finds the hostname.

Restart after any change:

sudo systemctl restart code-server@$USER

HTTPS with Caddy — a browser IDE has no business on plain HTTP

code.example.com {
    reverse_proxy 127.0.0.1:8080
}

That's the whole file, and it's enough because Caddy detects the WebSocket upgrade code-server's UI depends on and proxies it without extra configuration. Point the domain's A record at the VPS, let it propagate, and only then start Caddy — automatic HTTPS needs that record correct before it can request a certificate.

Read this before you buy: the NAT IPv4 catch for 443. Some overnight.host plans hand you 80 and 443 forwarded by default, some don't — check what your plan actually forwards before you point DNS anywhere, at NAT IPv4, ports and forwarding. If 443 isn't reachable, Caddy's automatic certificate issuance has nothing to answer the ACME challenge on, and it will sit there retrying instead of serving anything. A dedicated IPv4, where 443 is genuinely yours — on our plans that's arranged by e-mail — is the alternative; NAT IPv4 vs a dedicated IP covers the trade-off in more detail. Either way, a browser IDE must never end up reachable over plain HTTP on a public port — that password is the only thing standing between the internet and a terminal.

An IDE on the internet is a shell on your VPS

Say it plainly: code-server's whole value is a full terminal inside the browser tab, which means anyone who gets past auth: password has a shell on your machine, not just an editor. There's no built-in two-factor here — the password is doing all the work. A long, random, unique password is the floor, generated with something like openssl rand -base64 24 and stored in a password manager, not typed from memory.

Two ways to add a real second layer:

Caddy basic auth in front of it, which stacks a second credential Caddy checks before it ever proxies to code-server:

code.example.com {
    basic_auth {
        <username> <bcrypt-hash-from-caddy-hash-password>
    }
    reverse_proxy 127.0.0.1:8080
}

A VPN in front of the whole thing, so bind-addr and the Caddy site block only ever answer on an interface reachable through the tunnel, and the public internet never sees the hostname resolve to anything useful at all.

Pick at least one of these if the machine holds anything you'd mind losing.

Extensions come from Open VSX, not the Microsoft marketplace

code-server is configured out of the box to pull extensions from Open VSX (open-vsx.org), the open registry, rather than Microsoft's own marketplace — Microsoft's marketplace terms restrict its use to Microsoft's own products, and code-server isn't one. Install extensions the normal way, from the Extensions view in the UI or with code-server --install-extension <publisher.extension>, and it resolves against Open VSX automatically.

The catch worth knowing before you go looking for something: not every extension on the Microsoft marketplace has a matching listing on Open VSX. A handful of Microsoft-published ones simply aren't mirrored there, so if you're coming from desktop VS Code, budget a few minutes to confirm your must-haves exist before you build a whole workflow around them.

Settings Sync exists in code-server too, tied to a Microsoft or GitHub account, but it's worth treating as a convenience rather than a guarantee: because extensions still come from Open VSX on this end, syncing settings pulled from a desktop VS Code profile brings back the extensions that also exist on Open VSX and quietly skips the ones that don't.

Workspaces, and git over your dedicated SSH port

Your projects live as ordinary directories under your home directory on the VPS's own disk — no separate storage layer to configure, just ~/projects or wherever you'd naturally put them, opened from code-server's File → Open Folder. A handful of repos and their node_modules or build artifacts add up faster than the code itself, so keep an eye on df -h the same way you would on any other box.

Git works from the built-in terminal exactly as it would over SSH anywhere else — generate or copy an SSH keypair for this user, add the public half to GitHub, GitLab, or wherever your remotes live. The one thing that catches people out: if one of those remotes is a git server you also self-host behind NAT IPv4 — our own self-hosting Gitea on a VPS guide walks through exactly this — its SSH clone URL needs that server's forwarded port, not 22, so a plain git clone git@host:repo.git fails until you either add a Port line to ~/.ssh/config for that host or spell the port out in the URL.

Backups and updates

Two directories matter, and they're small: ~/.config/code-server (your config.yaml, including the password) and ~/.local/share/code-server (installed extensions and editor state), alongside whatever workspace directories you actually work in. None of that is backed up by anything running on the box on its own — copy it off the VPS on a schedule, the same as anything else you'd mind losing; back up your VPS covers what that looks like in practice.

Updating means installing a newer package: re-run the install script, which fetches the current release, or download the latest .deb from the releases page and sudo apt install it again the same way you did the first time, then sudo systemctl restart code-server@$USER to pick it up.

On overnight.host

Full disclosure: this is what we sell. The 2 GiB Basic is the realistic floor once a language server is actually running; the 1 GiB Starter only holds up for quick edits, and a build that leans on the CPU or a second service on the same box is a reason to move up to the 4 GiB Standard, not to fight the swap.

Order vps-basic → · Linux KVM VPS overview

FAQ

Can code-server compile a real project, not just edit files?

For light builds, yes — a script, a small service, a static site generator. For anything CPU- or memory-heavy, treat the VPS as an editor with a terminal attached, not a build farm, and run the actual compile step somewhere sized for it, or budget real RAM and CPU if you insist on doing it here.

Is a strong password enough, or do I need HTTPS too?

Both, always. HTTPS via Caddy stops the password itself from crossing the network in plain text; without it, anyone between you and the VPS can read the password off the wire the first time you type it in. A browser IDE reachable over plain HTTP is not a smaller risk than one with a weak password — it's the same risk from a different angle.

Why is an extension I use every day missing?

code-server pulls from Open VSX, not the Microsoft marketplace, and a small number of extensions — mostly Microsoft's own — are only published to the latter. Search Open VSX directly before assuming your install is broken; if it isn't listed there, it isn't coming through the Extensions view no matter what you try.

Can I browse or edit files outside my home directory?

Only as whatever your own Linux user can read or write, same as any shell session — code-server runs as you, under the systemd unit's %i substitution, with no extra privilege of its own. If a file needs sudo to touch from a terminal, it needs sudo here too, and code-server doesn't hand that out automatically.

What happens to my work if I just close the browser tab?

Nothing is lost. code-server runs as a systemd service on the VPS independent of any browser tab; closing the tab just disconnects the view. Unsaved editor state and any process you left running in an integrated terminal survive until you reconnect, restart the service yourself, or reboot the machine.

Originally published at overnight.host. We run a small, honest hosting company on dedicated bare metal: Linux & Windows VPS, game servers, web hosting. Live status at up.overnight.host.

Self-hosting Gitea on a VPS: SQLite vs Postgres, HTTPS, and the SSH port nobody warns you about

overnight.host — Mon, 14 Sep 2026 07:15:06 +0000

Gitea is a full GitHub-shaped forge — repos, issues, pull requests, a package registry, and now its own CI — in one small Go binary. The web half installs in five minutes. The part that actually costs an evening is git-over-SSH, because your VPS's SSH port is already spoken for.

SQLite or Postgres, and when it actually matters

Gitea, unlike some self-hosted apps that only pretend SQLite is an option, genuinely supports it in production for small teams. A single maintainer or a handful of collaborators pushing to a dozen private repos will not notice the database at all — it is one file, backed up by copying it, and there is nothing else to run.

Move to Postgres once either becomes true: several people are pushing and opening pull requests at the same time and you want real concurrent writes, or you are running Gitea Actions on the same box, where the runner and the web UI can both hit the database while a job is in flight. Postgres also makes backups cleaner later — a pg_dump is a text stream you can diff and restore selectively, where a SQLite file backup is all-or-nothing.

There is no in-place conversion between the two: outgrowing SQLite means exporting what you can, or scripting a migration, rather than flipping a config flag — decide early if you already know you'll have more than one or two regular committers.

Sizing: 1 GiB alone, 2 GiB once Actions run

Gitea itself is light. The Go binary, a handful of goroutines, and either SQLite or a thin Postgres connection: 1 GiB of RAM is genuinely comfortable for a personal instance, Caddy included.

The number that changes this is Actions. A CI job is a short-lived container doing real work — compiling, running a test suite, building an image — and while it runs it competes for the same RAM as Gitea and Postgres. Turn Actions on and point a runner at the same VPS, and plan for 2 GiB as the realistic floor, more if your builds pull large base images or compile anything non-trivial. Disk follows the same pattern: repos are usually small, but the Docker layer cache a runner accumulates is not, so keep an eye on it once jobs run regularly.

The compose file

Pin the image tag rather than tracking latest, so an upgrade is something you choose, not something that happens on a restart — the comment on the image line below is where to check for the current minor.

services:
  gitea:
    image: gitea/gitea:1.22  # check hub.docker.com/r/gitea/gitea/tags for the current minor
    restart: unless-stopped
    environment:
      - USER_UID=1000
      - USER_GID=1000
      - GITEA__server__DOMAIN=git.example.com
      - GITEA__server__ROOT_URL=https://git.example.com/
      - GITEA__server__SSH_DOMAIN=git.example.com
      - GITEA__server__SSH_PORT=2222
      - GITEA__server__SSH_LISTEN_PORT=22
      - GITEA__security__INSTALL_LOCK=true
      - GITEA__service__DISABLE_REGISTRATION=true
    volumes:
      - gitea_data:/data
      - /etc/timezone:/etc/timezone:ro
      - /etc/localtime:/etc/localtime:ro
    ports:
      - "127.0.0.1:3000:3000"
      - "2222:22"

volumes:
  gitea_data:

The web port is bound to 127.0.0.1 on purpose, so only the reverse proxy on the same host can reach it. The SSH port is deliberately not loopback-bound, because it has to be reachable from wherever you push from; more on the number 2222 below.

To move the database to Postgres, add a second service and point Gitea at it:

  db:
    image: postgres:16-alpine
    restart: unless-stopped
    environment:
      - POSTGRES_DB=gitea
      - POSTGRES_USER=gitea
      - POSTGRES_PASSWORD=${DB_PASSWORD}
    volumes:
      - db_data:/var/lib/postgresql/data

Add db_data: next to gitea_data: under the top-level volumes: block — Compose won't start a service that references an undeclared volume.

and add to the gitea service's environment, plus depends_on: [db]:

      - GITEA__database__DB_TYPE=postgres
      - GITEA__database__HOST=db:5432
      - GITEA__database__NAME=gitea
      - GITEA__database__USER=gitea
      - GITEA__database__PASSWD=${DB_PASSWORD}

Put the password in a .env file next to the compose file, not inline in the YAML:

printf 'DB_PASSWORD=%s\n' "$(openssl rand -hex 24)" > .env
chmod 600 .env

Bring the stack up, then create the admin account from the CLI:

docker compose up -d
docker compose exec -u git gitea gitea admin user create --username <you> --password '<strong-password>' --email you@example.com --admin

GITEA__security__INSTALL_LOCK=true above skips Gitea's /install wizard — without it, that page sits open and unauthenticated until you finish it by hand. GITEA__service__DISABLE_REGISTRATION=true matters too: Gitea's default is open self-registration.

HTTPS with Caddy

git.example.com {
    reverse_proxy 127.0.0.1:3000
}

That is the whole file. Caddy requests and renews the certificate for this hostname automatically as soon as it starts or reloads with this config, provided the A record already resolves to the machine — point DNS first, let it settle, and only then start Caddy.

Ports 80 and 443 aren't guaranteed forwarded either — some plans hand them to you by default, some don't, and Caddy needs at least one reachable to get a certificate. Check what your plan forwards before pointing DNS at the box; NAT IPv4, ports and forwarding is the same page the SSH story below sends you to.

Read this before you buy: the SSH port story

This is the part every other Gitea write-up glosses over. Your VPS almost certainly reaches SSH on a dedicated, non-standard port already — that is how sshd is exposed under NAT IPv4, and it is not something you can also hand to a container. Gitea's own SSH server needs a second forwarded port pointed at it, mapped to the container's internal port 22.

Concretely: your provider gives you a small number of forwarded ports besides the one used for host SSH. Say the next is 41023. You map it in compose as "41023:22" and set GITEA__server__SSH_PORT=41023 to match — but keep GITEA__server__SSH_LISTEN_PORT=22 right next to it, the way the compose file above already does. SSH_PORT only controls what Gitea advertises in clone URLs; SSH_LISTEN_PORT controls what it actually listens on inside the container, and it quietly defaults to whatever SSH_PORT is set to. Change one without pinning the other to 22, and Gitea's internal listener moves off port 22 too — nothing answers your "41023:22" mapping anymore, so git-over-SSH fails outright, connection refused, not just a wrong URL in the UI.

If you would rather not deal with a second forwarded port at all, git push/git clone over HTTPS with a personal access token works identically and needs nothing beyond the port Caddy already uses. Generate the token under Settings → Applications in Gitea's UI, and use it as the password when the CLI or credential helper asks. This is the honest fallback, not a downgrade — plenty of people run Gitea for years on HTTPS-only clones and never touch the SSH port.

Worth reading first: NAT IPv4 vs a dedicated IP and NAT IPv4, ports and forwarding.

Gitea Actions, and where the runner should live

Gitea Actions speaks most of the GitHub Actions workflow syntax, so .gitea/workflows/*.yml files using common actions mostly just work. It ships disabled; turn it on with GITEA__actions__ENABLED=true and restart.

Actions itself does no building — it dispatches jobs to act_runner, a separate process that registers against your instance and polls for work. Generate a registration token from inside the running container:

docker compose exec -u git gitea gitea actions generate-runner-token

Copy the printed token into .env as RUNNER_TOKEN=<token> — the runner block below reads it from there, and an empty value means a runner that never registers.

then point a runner at it:

  runner:
    image: gitea/act_runner:0.2.11  # check gitea.com/gitea/act_runner's tags for the current release
    restart: unless-stopped
    environment:
      - GITEA_INSTANCE_URL=https://git.example.com
      - GITEA_RUNNER_REGISTRATION_TOKEN=${RUNNER_TOKEN}
      - GITEA_RUNNER_NAME=vps-runner
    volumes:
      - runner_data:/data
      - /var/run/docker.sock:/var/run/docker.sock

Add runner_data: to that same volumes: block too (and db_data:, if you added Postgres).

That last mount is the thing to be honest about: giving the runner the Docker socket gives it effective root on the host, since it can start a container with the host filesystem mounted in. On a box that only runs Gitea and its own private repos, that's a reasonable trade. a self-hosted CI runner on a VPS covers sizing and isolation if your builds get heavier, or you want the runner on its own machine.

Backups with gitea dump

Gitea ships its own backup command, and it's the one to use — it snapshots the database, repos, hooks, and configuration together, instead of leaving you to reconstruct which copies were consistent with each other.

docker compose exec -u git gitea gitea dump -c /data/gitea/conf/app.ini

Run without a Postgres service attached, this also captures the SQLite file. The resulting zip lands inside the container's data directory; copy it off before it does anyone any good:

DUMP=$(docker compose exec -T gitea sh -c 'ls -t /data/gitea/gitea-dump-*.zip | head -n1')
docker cp "$(docker compose ps -q gitea):$DUMP" "./gitea-dump-$(date +%F).zip"

Copy that file off the VPS entirely — a dump on the same disk as the instance it came from is a file, not a backup. back up your VPS covers what off-machine backup means in practice. If you moved to Postgres, the dump still includes a database export, so a separate pg_dump is only needed for a faster point-in-time restore of a large database on its own.

Updates

docker compose pull
docker compose up -d

Bump the pinned tag deliberately, read the release notes for the version you're jumping to, and take a gitea dump immediately beforehand — Gitea runs migrations automatically on first start after an upgrade, and a migration you can roll back from is one where the backup came ten minutes earlier, not one you're improvising after the fact.

On overnight.host

Full disclosure: this is what we sell. If you want the repos without the sysadmin, the managed Gitea container comes with its own hostname and certificate — you get the app and a URL, not a root shell.

Order one-click-gitea → · One-click apps overview

FAQ

Can I use SQLite for a real team, or is it just for testing?

For a small team it is a real, supported option, not a toy — Gitea's SQLite backend handles a handful of concurrent users comfortably. Move to Postgres once several people are pushing at once, or you're running Actions on the same box — both add write concurrency SQLite wasn't designed for.

Why can't I just use my VPS's normal SSH port for git?

Because it is already in use by sshd for logging into the machine itself, and one port cannot be forwarded to two different listeners. Gitea's own SSH server needs its own forwarded port, mapped to the container, with SSH_PORT set to match for correct clone URLs and SSH_LISTEN_PORT pinned to 22 so the container's own listener still matches that mapping.

Do I need a dedicated IPv4 for this?

No. A second forwarded port for Gitea's SSH server is enough, and if your provider doesn't hand you a spare one, HTTPS with a personal access token works identically with no extra port at all. A dedicated IPv4 only matters if you want a standard port number instead; on our plans that's arranged by e-mail.

Where should the Actions runner live?

On the same VPS is fine at small scale, as long as you budget the RAM for it and accept the runner's Docker socket access as host-level power. Once builds get heavy, or you want a boundary between the git server and whatever your CI jobs execute, move the runner to its own box — a self-hosted CI runner on a VPS walks through sizing and isolation for that case.

What does gitea dump actually back up?

The database (including a SQLite file, if that's what you're running), the repository data, custom configuration, hooks, and logs, bundled into one zip with -c pointing at your app.ini — the one command that guarantees the pieces are consistent with each other, which copying files by hand doesn't.

Written by the person who runs overnight.host: a small, honest hosting company on dedicated bare metal — Linux VPS, game servers, web hosting. Live status at up.overnight.host.

Originally published at overnight.host — the canonical, kept-current version of this guide.

Your own WireGuard VPN on a VPS: the NAT port has to match

overnight.host — Sun, 13 Sep 2026 19:15:16 +0000

WireGuard is a few hundred lines of kernel code and two small config files, and the whole setup takes about fifteen minutes once you know which port to open. The part that actually trips people up on a budget VPS is not WireGuard at all — it is that the port you tell WireGuard to listen on has to be one the provider already forwards to you.

What WireGuard actually is

WireGuard is not a service you install and forget about; it is a network interface. The kernel module has shipped in mainline Linux since version 5.6, so on Ubuntu 24.04 it is already part of the kernel you booted — there is no dkms build, no compiling against headers, nothing to break on a kernel update. What you install is wireguard-tools, which gives you two commands: wg, for keys and status, and wg-quick, which reads a config file and brings the interface up or down as a single unit.

That simplicity is also the constraint. There is no built-in dashboard, no user accounts, and no bandwidth graph. Every peer, on either end, is one public key and one line of config. Getting comfortable editing a text file by hand is the whole job.

Read this before you buy: the NAT IPv4 port catch

Cheap VPS plans very commonly give you NAT IPv4 — one shared public address with a small, fixed set of forwarded ports — rather than an address that is yours alone. That is fine for outbound connections, which is all a WireGuard client ever makes. It matters the moment your VPS is the WireGuard server, because a server has to accept an inbound connection on a specific UDP port, and behind NAT you cannot just pick 51820 because a guide told you to.

The rule is simple once you know it: ListenPort in your server config must be set to one of the ports your provider actually forwards to your machine, and the client's Endpoint must use that same port. Pick a random port instead and the tunnel will look correctly configured on both ends and simply never connect, because the packets never reach your VPS in the first place.

Two ways through it:

Use one of the forwarded ports you already have. WireGuard does not care what number it runs on, so point ListenPort at whichever forwarded port is free and move on.
Get a dedicated IPv4. With an address of your own, any port is yours to open, including the WireGuard default. On our plans a dedicated IPv4 is available on request by e-mail, not as a self-service add-on.

Read NAT IPv4 vs a dedicated IP and NAT IPv4, ports and forwarding before you order if you are not sure which situation you are in.

Step 1: a clean machine

Deploy an Ubuntu 24.04 LTS VPS, then do the boring security work before anything is exposed to the internet: a non-root user, your SSH key on it, password login switched off, and a firewall that defaults to deny. We walk through that in connect to your VPS over SSH and secure your VPS.

Note the forwarded UDP port range or list from your provider's panel before you go further — you need an actual number for the next step, not a placeholder.

Step 2: install WireGuard and generate keys

sudo apt update
sudo apt install -y wireguard

That pulls in wireguard-tools; the kernel side is already present. Installing it also creates /etc/wireguard owned by root with mode 0700, so your regular sudo user cannot cd into it or write a key there — generate the server's key pair as root, with a strict umask so the private key is never briefly world-readable:

sudo -i
cd /etc/wireguard
umask 077
wg genkey | tee server_private.key | wg pubkey > server_public.key
exit

Do the whole block in one root shell rather than prefixing each line with sudo — sudo does not inherit the umask 077 you just set, so a command like sudo tee can still create the key file with its own default, more permissive mode even though the umask line ran.

Generate a second pair for the client the same way, on whichever machine will hold it — it does not have to be the server. Keep the two private keys apart; only the matching public key ever leaves its own side.

Step 3: the server config, routing and NAT

Create /etc/wireguard/wg0.conf, using one of your forwarded ports for ListenPort:

[Interface]
PrivateKey = <server_private.key contents>
Address = 10.66.66.1/24
ListenPort = 41194
PostUp = iptables -t nat -A POSTROUTING -o <WAN_INTERFACE> -j MASQUERADE; iptables -A FORWARD -i wg0 -j ACCEPT
PostDown = iptables -t nat -D POSTROUTING -o <WAN_INTERFACE> -j MASQUERADE; iptables -D FORWARD -i wg0 -j ACCEPT

[Peer]
PublicKey = <client public key>
AllowedIPs = 10.66.66.2/32

Replace <WAN_INTERFACE> with your real outbound interface name, not eth0. Find it first:

ip -brief link

This is the thing that bites later: most published examples hardcode eth0, but plenty of KVM images come up as ens3, enp1s0 or similar. Get the name wrong and the tunnel connects fine, wg show looks healthy, and the client still has no internet through it, because the MASQUERADE rule silently applies to an interface that does not exist.

Turn on IP forwarding and make it survive a reboot:

echo 'net.ipv4.ip_forward=1' | sudo tee /etc/sysctl.d/99-wireguard.conf
sudo sysctl --system

Step 4: firewall, and the port that has to match

Open the same forwarded port, over UDP, and nothing else new:

sudo ufw allow 41194/udp

WireGuard is UDP end to end. A rule that opens the port as TCP by mistake produces the same symptom as picking a non-forwarded port: everything looks configured and nothing arrives. If you change the listen port later, update it in three places at once — the config file, the firewall rule, and every client's Endpoint — or you will spend ten minutes debugging a mismatch you made yourself five minutes earlier.

If you followed Step 1's advice and have ufw running, there is a second gate to check: ufw ships with DEFAULT_FORWARD_POLICY="DROP" in /etc/default/ufw, which blocks exactly the routed, NAT'd traffic this tunnel exists to move, regardless of the port being open. Edit that file, set DEFAULT_FORWARD_POLICY="ACCEPT", and run sudo ufw reload before you test a client — leave it on DROP and the handshake still completes and wg show still looks healthy, but the client has no internet through the tunnel.

Step 5: one client config

This is the entire client side, for the official WireGuard app on any platform or for wg-quick on another Linux box:

[Interface]
PrivateKey = <client private key>
Address = 10.66.66.2/32
DNS = 1.1.1.1

[Peer]
PublicKey = <server_public.key contents>
Endpoint = 203.0.113.10:41194
AllowedIPs = 0.0.0.0/0
PersistentKeepalive = 25

Replace 203.0.113.10 with your VPS's public NAT IPv4 address and 41194 with the forwarded port from Step 3. AllowedIPs = 0.0.0.0/0 routes all of the client's traffic through the tunnel, which is what most people mean by "my own VPN" — narrow it to specific subnets if you only want the tunnel for part of your traffic. PersistentKeepalive = 25 matters specifically because the client usually sits behind its own NAT (a home router, a phone on mobile data); without it, that NAT's connection tracking entry expires during idle periods and the server cannot reach the client until it sends something first.

Keeping it running

Bring the interface up and enable it for every future boot in one command:

sudo systemctl enable --now wg-quick@wg0

Check it with sudo wg show, which lists the peer, the last handshake time and the bytes moved in each direction — a peer with no handshake ever recorded means the packets are not arriving, which sends you back to Step 3's interface name or Step 4's port. sudo systemctl status wg-quick@wg0 and journalctl -u wg-quick@wg0 cover the rest.

There is no key rotation schedule to maintain and no update service running that needs restarting on a cadence — WireGuard's attack surface is deliberately small. The two things actually worth a recurring check: that wireguard-tools picks up routine security updates with the rest of the system (sudo apt update && sudo apt upgrade), and that nothing in your provider's panel changes which ports are forwarded to you, since that is the one setting this whole guide hangs off.

What a VPN in Dallas or Charlotte does and does not hide

Our machines run in Dallas, TX and Charlotte, NC, so a WireGuard server there gives you a US exit address — sites you visit see that VPS's IP, not your home or mobile connection's. Inside the tunnel, your local network operator, your ISP and anyone else between you and the VPS sees only encrypted WireGuard packets to one UDP port; they cannot read what is inside them or which sites you are actually visiting.

What it does not do is anonymise you. Any site you log into still recognises you as you, regardless of which IP address you arrive from. Browser fingerprinting is unaffected — cookies, canvas fingerprinting and account sessions do not care what your network path looks like. Your traffic's final destination is also visible to the operator of that VPS, because unlike a multi-hop system such as Tor, this is a single hop: your ISP no longer sees your browsing, but something has to terminate the tunnel and see the traffic in cleartext before it goes onward, and that something is your own VPS. Geolocation-wise, expect exactly one change: sites that check IP location will place you in Texas or North Carolina, and a few services that treat datacentre address ranges differently from residential ones may notice that too.

On overnight.host

Full disclosure: this is what we sell. A 1 vCPU, 1 GiB Starter runs a personal WireGuard tunnel without noticing it; move up a tier only once you are pushing serious throughput or running several always-on tunnels off the same box.

Order vps-starter → · Linux KVM VPS overview

FAQ

Do I need a dedicated IPv4 to run WireGuard?

No. NAT IPv4 works fine as a WireGuard server as long as ListenPort in your config is one of the ports your provider forwards to you, and every client's Endpoint uses that same port. A dedicated IPv4 only becomes useful if you want to run more services than you have forwarded ports for, or want the default port specifically.

Why does my tunnel show as configured but nothing connects?

The two most common causes are a ListenPort that is not actually forwarded to your VPS, and a firewall rule opened as TCP instead of UDP. Check sudo wg show for a peer with no recorded handshake — that confirms packets are not arriving at all, which points at the port rather than at routing or keys.

Can I run more than one client?

Yes. Add one [Peer] block per client to the server config, each with its own public key and its own /32 address inside your chosen subnet, then reload with sudo wg syncconf wg0 <(wg-quick strip wg0) or a restart of the service. Every client keeps its own private key; only public keys go on the server.

Does WireGuard hide what I do from my VPS provider?

No. The VPS is where your tunnel ends and your traffic goes back onto the open internet in cleartext, so whoever controls that machine could, in principle, see it — the same is true of any VPS you use for anything. What the tunnel does hide is your traffic from your local network and your ISP between your device and that VPS.

How much does WireGuard cost to run?

Nothing beyond the VPS itself. It is a kernel feature and a command-line tool, both free, with no license and no per-peer fee. A personal tunnel for one or two people idles well inside a 1 GiB Starter; sizing up only matters once you are pushing meaningful throughput through it continuously.

Written by the person who runs overnight.host: a small, honest hosting company on dedicated bare metal — Linux VPS, game servers, web hosting. Live status at up.overnight.host.

Originally published at overnight.host — the canonical, kept-current version of this guide.

Self-hosting Nextcloud properly: storage, cron, and the settings everyone gets wrong

overnight.host — Sat, 12 Sep 2026 07:18:23 +0000

Nextcloud installs in ten minutes and then spends two years being mysteriously slow. Almost all of it comes down to four settings and one decision about where the files live.

Decide the shape first

There are three sane ways to run it, and picking the wrong one is the expensive mistake.

Nextcloud AIO — an all-in-one master container that manages the rest for you. Good defaults, handles backups and updates, and it wants the Docker socket and a port of its own. Easiest if you want opinions rather than knobs.
Plain Docker Compose — Nextcloud, a database and Redis as three services you own. More work, total control, and the shape used below.
A managed instance — someone else's problem entirely. Fine choice if the point was the files, not the server.

What is not a sane way: SQLite. Nextcloud will let you, and it works right up until two devices sync at once.

Sizing: it is a disk problem, not a CPU problem

Nextcloud is a file server with a web UI. CPU matters for thumbnail generation and the occasional big scan; the thing that actually runs out is disk.

Budget for what you will store in two years, not what you have today, and remember the multiplier: a file that exists on your laptop, your phone and the server exists three times, and versioning keeps old copies of anything you edit. 2 GiB of RAM is a comfortable floor for a small household instance with Redis alongside; the database is small unless you have hundreds of thousands of files.

If the disk is the constraint, plan how you grow it before you fill it — add extra storage to your VPS covers the mechanics on our machines.

The compose file

services:
  db:
    image: mariadb:11.4
    restart: unless-stopped
    command: --transaction-isolation=READ-COMMITTED --log-bin=binlog --binlog-format=ROW
    environment:
      - MARIADB_ROOT_PASSWORD=${DB_ROOT_PASSWORD}
      - MARIADB_DATABASE=nextcloud
      - MARIADB_USER=nextcloud
      - MARIADB_PASSWORD=${DB_PASSWORD}
    volumes:
      - db:/var/lib/mysql

  redis:
    image: redis:7-alpine
    restart: unless-stopped

  app:
    image: nextcloud:30-apache
    restart: unless-stopped
    depends_on: [db, redis]
    environment:
      - MYSQL_HOST=db
      - MYSQL_DATABASE=nextcloud
      - MYSQL_USER=nextcloud
      - MYSQL_PASSWORD=${DB_PASSWORD}
      - REDIS_HOST=redis
      - NEXTCLOUD_TRUSTED_DOMAINS=cloud.example.com
      - OVERWRITEPROTOCOL=https
      - PHP_MEMORY_LIMIT=512M
      - PHP_UPLOAD_LIMIT=10G
    volumes:
      - nextcloud:/var/www/html
    ports:
      - "127.0.0.1:8080:80"

  cron:
    image: nextcloud:30-apache
    restart: unless-stopped
    depends_on: [db, redis]
    volumes:
      - nextcloud:/var/www/html
    entrypoint: /cron.sh

volumes:
  db:
  nextcloud:

The fourth service is not optional, and it is the one most guides leave out. Read on.

The four settings everyone gets wrong

1. trusted_domains. Nextcloud refuses any hostname it was not told about, with a blunt "access through untrusted domain" page. Set it at install (NEXTCLOUD_TRUSTED_DOMAINS above) or fix it later in config/config.php. Add every name you will really use, including the one you use from inside your own network.

2. overwriteprotocol. Behind a reverse proxy that terminates TLS, PHP sees plain HTTP and starts generating http:// links inside an https:// page. Browsers block them and the UI half-breaks. OVERWRITEPROTOCOL=https fixes it. If your proxy is on a different host, set trusted_proxies too, or every login shows up in the logs from the proxy's address instead of the user's.

3. Background jobs. A default install runs its background jobs via AJAX, meaning "when somebody happens to load a page". File scans, previews, cleanup and notifications then run late or never, and the instance feels slower every month. The cron service above is the fix: the same image with /cron.sh as the entrypoint, sharing the volume. Then set the method to Cron in Administration → Basic settings.

4. Upload limits. They are enforced in three places and the smallest wins: PHP (PHP_UPLOAD_LIMIT), the reverse proxy body size, and any intermediate CDN. Raising one and forgetting the others is why "it fails at exactly 512 MB".

HTTPS and the proxy

cloud.example.com {
    reverse_proxy 127.0.0.1:8080
    request_body {
        max_size 10GB
    }
    header {
        Strict-Transport-Security "max-age=31536000;"
    }
    redir /.well-known/carddav /remote.php/dav 301
    redir /.well-known/caldav /remote.php/dav 301
}

Those two redirects are what silence the "your web server is not properly set up to resolve /.well-known/caldav" warning, and without them contact and calendar sync in some clients simply does not find the server. Point the DNS record first — point your domain at your service if you have not done that before.

After the install: run the checks

The admin overview page has a security & setup warnings section. Do not treat it as decoration; it is a genuine checklist. The two that matter most on a fresh install:

docker compose exec -u www-data app php occ db:add-missing-indices
docker compose exec -u www-data app php occ db:add-missing-primary-keys

Nextcloud ships new indices with new versions but will not add them to a live database on its own, and a table without them gets slow in a way that looks like "the server is underpowered".

Backups

Three things, and you need all three:

the database — mysqldump (or mariadb-dump) of the nextcloud database;
the data directory — the files themselves, which is the big one;
config/config.php — small, and irritating to reconstruct.

Put the instance into maintenance mode first so the dump and the files agree with each other:

docker compose exec -u www-data app php occ maintenance:mode --on
# dump the database, copy the data directory
docker compose exec -u www-data app php occ maintenance:mode --off

Copy the result off the machine. Nothing about self-hosting includes a backup by default — that part is yours to arrange, on any provider. back up your VPS is our own write-up of what that means in practice.

On overnight.host

Full disclosure: this is what we sell. If you want the app without the sysadmin, we run Nextcloud as a managed container with its own volume and hostname — you get the app and a URL, not a root shell.

Order one-click-nextcloud → · One-click apps overview

FAQ

How much disk does Nextcloud need?

As much as the files, plus room for file versions and the trash, plus the previews it generates. Size for what you expect in two years rather than what you have now, and check the versioning and retention settings early — they are the quiet consumers.

Can I use SQLite?

Only for a look-around. Nextcloud supports it, but it serialises writes and falls over as soon as two clients sync at the same time. MariaDB or PostgreSQL for anything you intend to keep.

Why are my uploads failing at a fixed size?

Something in the chain has a body-size limit smaller than the file. Check PHP's upload and post limits, the reverse proxy's max body size, and any CDN in front. The smallest number wins, and it is usually the proxy.

Do I need Redis?

Strongly recommended. Nextcloud uses it for transactional file locking and caching; without it you eventually meet the "file is locked" errors under concurrent sync. It costs a few megabytes of RAM.

Is a managed Nextcloud different from self-hosting?

Functionally it is the same application. The difference is who holds the root shell: with a managed container you get the app, a hostname and a certificate, and you do not get to install PHP extensions or run occ yourself. If you need that control, put it on a VPS instead.

Written by the person who runs overnight.host: a small, honest hosting company on dedicated bare metal — Linux VPS, game servers, web hosting. Live status at up.overnight.host.

Originally published at overnight.host — the canonical, kept-current version of this guide.

Self-hosting Vaultwarden on a VPS: HTTPS, the admin token, and the NAT catch

overnight.host — Fri, 11 Sep 2026 23:12:35 +0000

A password vault is the one self-hosted app where "mostly working" is not good enough. Vaultwarden is small, fast on a fraction of a gigabyte, and every serious client refuses to talk to it without a real certificate — which is the part that actually takes the twenty minutes.

What Vaultwarden is, and is not

Vaultwarden is a from-scratch server implementation of the Bitwarden sync API, written in Rust, distributed as a single small Docker image. It is not Bitwarden's own server software (that project is the much heavier bitwarden/server stack) and it is not affiliated with Bitwarden the company — it is a community project that happens to speak the same protocol, so the official Bitwarden apps and browser extensions work against it once you point them at your own server URL. That compatibility is the entire pitch: your phone, laptop and browser extension do not know or care that the server on the other end is Vaultwarden.

Why HTTPS is not optional here

Every other app in this series can limp along on plain HTTP for testing. Vaultwarden cannot, and the reason is not policy, it is the client software. The web vault runs inside your browser, and once that page is loaded over HTTPS, mixed-content rules block it from talking to a plain http:// server — the browser refuses the request before it leaves the page. The mobile app and browser extension add their own validation on top and reject a non-HTTPS, non-localhost server URL outright, regardless of what the browser would allow. Try to add a plain-http:// server URL anywhere but localhost and it gets refused before it ever reaches your container. There is no setting that turns this off, because it is not Vaultwarden's rule to relax.

Practically this means: get a real hostname and a real certificate before you try to log in from a client, not after. A self-signed certificate does not fix it either — the clients want something a normal trust store accepts, so a real domain behind Let's Encrypt (or equivalent) is the actual requirement, not an optional nicety.

Read this before you buy: the NAT IPv4 catch

Cheap VPS plans very often hand you NAT IPv4 — one shared public address with a short list of forwarded ports — rather than an address that is entirely yours. That is fine for outbound traffic and for SSH on a non-standard port, but it changes how you expose HTTPS.

If 443 is one of your forwarded ports, point your domain at the VPS, run Caddy on 443 as below, and everything in this guide works exactly as written.
If it is not, you cannot bind the standard HTTPS port, so the honest fix is to run Caddy on whatever port you were given and put that port in the client's server URL — https://vault.example.com:8443, say. Every Bitwarden client accepts a port in the server URL field; it is one extra field at setup, not a limitation of the protocol. This only works if port 80 is also forwarded to you: Caddy serves the site itself on 8443, but still needs 80 free to complete the HTTP-01 challenge that gets the certificate from Let's Encrypt in the first place. If 80 is not forwarded either, automatic HTTPS on a non-standard port needs a DNS-01 challenge instead — a Caddy build with your DNS provider's plugin, which the stock image does not ship, plus API credentials — so ask about the dedicated IPv4 below if that is on the table.
The third option is a dedicated IPv4, which gives you 443 outright. On our plans that is available on request by e-mail, not as a self-service add-on.

Worth reading first: NAT IPv4 vs a dedicated IP and NAT IPv4, ports and forwarding.

The compose file

Pin the image tag. Vaultwarden ships new releases regularly and some of them change the database schema, so latest on a vault you actually rely on is a bad trade for saving one line of maintenance. Check the current release at the project's GitHub releases page before copying the tag below — this guide will drift out of date, and running whatever is current matters more than this exact number.

services:
  vaultwarden:
    image: vaultwarden/server:1.32.7
    restart: unless-stopped
    environment:
      - DOMAIN=https://vault.example.com
      - SIGNUPS_ALLOWED=false
      - ADMIN_TOKEN=${ADMIN_TOKEN}
      - WEBSOCKET_ENABLED=true
    volumes:
      - vw-data:/data
    ports:
      - "127.0.0.1:8080:80"

volumes:
  vw-data:

The port is bound to 127.0.0.1 on purpose: nothing but the reverse proxy on the same host can reach Vaultwarden directly, so a stray scanner hitting the VPS's public address on port 8080 finds nothing.

Generate the admin token before first boot, not after, then hash it rather than storing it raw:

docker run --rm -it vaultwarden/server:1.32.7 /vaultwarden hash

That prompts for a password — paste the output of openssl rand -base64 48 into it — and prints an Argon2 PHC string. Put that string, not the raw random value, into .env, wrapped in single quotes — an Argon2 string is full of $ signs, and Docker Compose would otherwise try to expand them as variables and hand Vaultwarden a mangled token:

printf "ADMIN_TOKEN='%s'\n" 'paste-the-argon2-phc-string-here' > .env
chmod 600 .env

Vaultwarden accepts a plain token too, but the hashed form is the one its own documentation recommends — it is not vulnerable to timing-attack recovery from the /admin login the way a raw comparison is.

Signups, off by default

SIGNUPS_ALLOWED=false matters more here than the equivalent setting does on most self-hosted apps, because a vault is the one place a stranger creating their own account is a genuinely bad outcome, not just clutter. Leave signups closed and create your own accounts through the /admin page instead, using the token above. If you do want a second household member in, invite them from an existing account rather than reopening signups — invitations work with SIGNUPS_ALLOWED=false set.

The /admin page itself is worth locking down further once you are done using it day to day: it accepts the same token forever unless you rotate it, so treat that token like a root password, not like an application setting.

HTTPS with Caddy

vault.example.com {
    reverse_proxy 127.0.0.1:8080
}

That is the whole file — Caddy requests and renews the certificate on its own the first time it sees a request for that hostname, provided DNS already points at the machine. Point the A record first and let it settle; point your domain at your service covers that if you have not done it before. If you are on the forwarded-port path from the NAT section above, change the site block to vault.example.com:8443, open that port, and make sure 80 is forwarded too — Caddy serves the site on 8443 but still needs 80 open to fetch and renew the certificate itself.

WebSockets need to pass through cleanly for live sync between devices to work — Caddy's reverse_proxy handles the Upgrade/Connection headers automatically, which is one less thing to get wrong compared with a manually written nginx config.

Sizing: this one is genuinely small

Vaultwarden is a single Rust binary and a SQLite file holding encrypted blobs — there is no PHP runtime, no Node process, no in-memory cache to budget for. 1 GiB of RAM is plenty, including room for Caddy and the OS itself, even with a handful of accounts and a few hundred items each. Disk is dominated by attachments, if you use them, and those are also usually small. This is the rare self-hosted app where the constraint is not sizing at all — it is getting HTTPS right.

Backups: three things, not one

The data volume holds more than a database, and all of it needs to leave the machine together.

the SQLite database (db.sqlite3) — accounts, encrypted vault items, organizations;
attachments, stored as files under the same data directory;
the RSA key pair (rsa_key.pem, rsa_key.pub.pem) that Vaultwarden generates on first boot and uses to sign authentication tokens — lose it and every existing client session invalidates, forcing a re-login everywhere, though the vault data itself is still readable.

All three live under /data inside the container, so a volume-level copy catches everything in one pass — but stop the container first. db.sqlite3 is a live database while Vaultwarden runs, and a raw copy taken mid-write can land on a torn, inconsistent snapshot; a few seconds of downtime is cheap insurance against a backup that turns out useless the day you need it.

docker compose stop vaultwarden
docker run --rm \
  -v vw-data:/data:ro \
  -v "$PWD":/backup \
  alpine:3.20 tar czf /backup/vaultwarden-$(date +%F).tar.gz -C /data .
docker compose start vaultwarden

Run it on a schedule and copy the result off the VPS entirely — a tarball sitting next to the volume it came from does not survive the disk it is on failing. back up your VPS is our own write-up of what off-machine backup actually means in practice, on any provider.

Updates

docker compose pull
docker compose up -d

Bump the pinned tag deliberately rather than tracking latest, and skim the release notes first — Vaultwarden documents schema migrations and any breaking environment-variable changes per release, and they run automatically against your SQLite file on the next start. Take the backup above immediately before an update on a vault you cannot afford to lose; a failed migration is rare, but a vault is exactly the file you do not want to find that out about the hard way.

On overnight.host

Full disclosure: this is what we sell. If you want the app without the sysadmin, the managed Vaultwarden container comes with its own hostname and certificate — you get the app and a URL, not a root shell.

Order one-click-vaultwarden → · One-click apps overview

FAQ

Can I use Vaultwarden over plain HTTP for testing?

Only from localhost, because that is the one address every Bitwarden client also treats as trusted. Anything reached over a network — your phone, a different machine, even another device on your own LAN — needs real HTTPS before the clients will accept the server URL: the web vault is blocked by its own browser's mixed-content rules, and the mobile app and extension refuse a non-HTTPS, non-localhost URL by their own validation regardless of what the browser would allow.

Do I need a dedicated IPv4?

No. A forwarded port for 443 works fine, and if you were not given one, running HTTPS on a non-standard port and putting that port in the client's server URL works exactly as well. A dedicated IPv4 is only for when you want the standard port without any of that, and on our plans it is arranged by e-mail rather than self-service.

Is Vaultwarden as secure as Bitwarden's own server?

It implements the same client-side encryption model — your vault is encrypted and decrypted on your device, and the server only ever stores ciphertext — so a compromise of the server does not hand over readable vault contents either way. What differs is who wrote and maintains the server code: Vaultwarden is an independent, community-maintained reimplementation, not Bitwarden's own software.

What happens if I lose the RSA key pair?

Every client gets logged out and has to re-authenticate, because the tokens they were holding were signed with a key that no longer exists. Your vault data is unaffected — it is encrypted with your own master password, not with that key pair — but it is still a bad afternoon, which is why the key pair is one of the three things backed up above, not an afterthought.

Can I turn signups back on later for one more person?

You do not need to. Existing accounts can send invitations while SIGNUPS_ALLOWED stays false, so a new household member gets in without the vault being open to anyone who finds the URL in between.

Written by the person who runs overnight.host: a small, honest hosting company on dedicated bare metal — Linux VPS, game servers, web hosting. Live status at up.overnight.host.

Running a trading bot on a Linux VPS 24/7: systemd, chrony, and a kill switch you've actually tested

overnight.host — Fri, 11 Sep 2026 23:10:19 +0000

A trading bot that only runs when your laptop is open is not a trading bot, it is a demo. Getting it onto a server that stays up is the easy part; the part that actually matters is boring operations work — restart policy, clock sync, and knowing the bot is still alive without staring at a terminal.

What this covers, and what it doesn't

This is an operations guide: running a Python trading bot as a long-lived Linux process that restarts sanely, keeps credentials off disk in the wrong place, agrees with the exchange about what time it is, and tells you when it dies. It does not cover strategy, order types, backtesting, or position sizing — that is your call to make, and nothing here is financial advice. Assume you already have a working bot that talks to an exchange's API and just need it to run unattended without becoming a liability.

Sizing the machine

A single bot process is a light workload. A Python process holding a websocket connection, a small in-memory order book, and a logging pipeline typically sits well under 300 MB resident. The 1 GiB Starter tier covers one bot with headroom for the OS and chrony. What actually pushes you up a tier is running several bots on one box, keeping a local database of fills and candles that grows for months, or backtesting on the same machine you trade from — batch work and a live process fight over the same cores. Keep those separate if you can.

Disk is rarely the constraint: a bot's code, a virtualenv, and months of rotated JSON logs fit inside a few gigabytes. The 25 GB on Starter is plenty unless you're recording full market data ticks, a different sizing conversation entirely.

Step 1: a clean, outbound-only machine

Deploy an Ubuntu LTS image, then do the basics before anything touches the network: a non-root user, an SSH key, password login off, and a firewall that defaults to deny. Walkthroughs for both are at connect to your VPS over SSH and secure your VPS.

This workload only calls out — REST calls and a websocket to the exchange, nothing listening for inbound connections — so the shared, NAT-style IPv4 most budget VPS plans hand out by default is irrelevant here. No dedicated address or forwarded port needed for anything in this guide.

Create a dedicated system user for the bot rather than running it as your own login or as root:

sudo useradd --system --create-home --shell /usr/sbin/nologin botuser
sudo mkdir -p /opt/trading-bot/data
sudo chown -R botuser:botuser /opt/trading-bot

Deploy your code under /opt/trading-bot and build the virtualenv as botuser, not as yourself:

sudo -u botuser python3 -m venv /opt/trading-bot/venv
sudo -u botuser /opt/trading-bot/venv/bin/pip install -r /opt/trading-bot/requirements.txt

Step 2: the bot as a systemd service

A bot running in a tmux session survives an SSH disconnect but not a reboot, a crash, or you forgetting which pane it's in. A systemd unit survives all three and gives you a restart policy for free:

[Unit]
Description=trading-bot
After=network-online.target chrony.service
Wants=network-online.target
StartLimitIntervalSec=300
StartLimitBurst=5

[Service]
Type=simple
User=botuser
Group=botuser
WorkingDirectory=/opt/trading-bot
EnvironmentFile=/etc/trading-bot/env
ExecStart=/opt/trading-bot/venv/bin/python /opt/trading-bot/bot.py
Restart=on-failure
RestartSec=5
NoNewPrivileges=true
ProtectSystem=strict
ReadWritePaths=/opt/trading-bot/data
PrivateTmp=true

[Install]
WantedBy=multi-user.target

Two choices here are deliberate. StartLimitIntervalSec=300 with StartLimitBurst=5 stops a crash loop from hammering the exchange's API forever — after five restarts in five minutes, systemd gives up and leaves the unit stopped instead of retrying into a rate-limit ban. And Restart=on-failure, not Restart=always, only restarts the process on a non-zero exit status. That distinction is the whole point of the kill switch in Step 7, so hold onto it.

Enable it now. Don't start it yet — the unit's EnvironmentFile doesn't exist until Step 3, and systemd refuses to start a service whose EnvironmentFile is missing:

sudo systemctl daemon-reload
sudo systemctl enable trading-bot.service

The systemd.service manual documents every directive above if you want the exact semantics rather than my summary of them.

Step 3: API keys in a root-only file, never in the repo

The exchange API key and secret don't belong in your code, in a .env committed by accident, or in a config file readable by every user on the box. They belong in an EnvironmentFile only root can read:

sudo mkdir -p /etc/trading-bot
sudo touch /etc/trading-bot/env
sudo chown root:root /etc/trading-bot/env
sudo chmod 600 /etc/trading-bot/env

EXCHANGE_API_KEY=your-key-here
EXCHANGE_API_SECRET=your-secret-here

This works even though the service runs as the unprivileged botuser: systemd, running as root, reads EnvironmentFile before dropping privileges to start your process, and hands the resulting variables to the already-running process. The file itself never needs to be readable by botuser, so chmod 600 owned by root is the correct, final permission — not a temporary one you loosen later because something "couldn't read it."

Add the file's path to .gitignore before you write anything into it, and check with git status that it never shows up as untracked or staged. A key that reaches a private repo is still a key that reached a repo; rotate it if you're ever unsure.

Now that /etc/trading-bot/env exists, start the service you enabled in Step 2:

sudo systemctl start trading-bot.service
sudo systemctl status trading-bot.service

Step 4: clock sync with chrony

Most exchange APIs sign requests with a timestamp and reject anything outside a tolerance window, often a few seconds. A drifted VPS clock gets -1021-style "timestamp outside recvWindow" errors on every signed call — it looks exactly like a broken bot and is actually a broken clock.

Ubuntu 24.04 ships systemd-timesyncd by default, which is fine for most things but coarser than you want here. Chrony is the better fit for a machine that needs a tight, actively-monitored offset:

sudo apt update
sudo apt install -y chrony
sudo systemctl disable --now systemd-timesyncd
sudo systemctl enable --now chrony

Confirm it's actually tracking, not just running:

chronyc tracking
chronyc sources -v

chronyc tracking should show a System time offset in the low milliseconds within a minute or two of starting. If it stays wide, check outbound UDP 123 isn't blocked by your firewall rules. The chrony documentation covers tuning makestep and source selection if the defaults don't converge fast enough.

Step 5: structured logging you can actually grep at 3am

Plain print() statements are fine for development and useless at 3am when you need the one line that explains why an order didn't go through. Log as JSON, one object per line, and let journald capture stdout — no separate log file needed:

import json
import logging
import sys
import time


class JsonFormatter(logging.Formatter):
    def format(self, record):
        payload = {
            "ts": time.strftime("%Y-%m-%dT%H:%M:%SZ", time.gmtime(record.created)),
            "level": record.levelname,
            "logger": record.name,
            "msg": record.getMessage(),
        }
        if record.exc_info:
            payload["exc"] = self.formatException(record.exc_info)
        return json.dumps(payload)


handler = logging.StreamHandler(sys.stdout)
handler.setFormatter(JsonFormatter())
logging.basicConfig(level=logging.INFO, handlers=[handler])

Because systemd already timestamps everything it captures, ask journalctl for the raw JSON without its own prefix when you want to pipe it somewhere:

journalctl -u trading-bot.service -o cat -f

journalctl rotates and caps its own storage by default, so you're not manually managing log files. If you add a second destination — a file, a shipper off-box — cap its size explicitly; an unbounded log file is a slow, quiet way to run out of disk.

Step 6: a heartbeat so a dead bot doesn't stay dead

systemctl status tells you the process is running, not that it's doing anything useful — a bot can be alive, connected, and stuck in a loop that stopped placing orders hours ago, and Restart=on-failure never fires because nothing crashed.

A dead man's switch fixes this, and it's a natural fit for an outbound-only bot: at the end of every successful loop, ping a monitoring URL.

import urllib.request

def send_heartbeat(url: str) -> None:
    try:
        urllib.request.urlopen(url, timeout=5)
    except Exception:
        pass  # a missed heartbeat should never crash the bot

Call send_heartbeat() once per loop, after the real work succeeds, not before it. Pair it with a service that expects a ping on a schedule and pages you when one doesn't arrive — healthchecks.io is the standard example, and it's open source if you'd rather run it yourself. The mechanism matters more than the service: silence is the alert, which is exactly what catches a bot that's technically running but has quietly stopped doing anything.

Step 7: test the kill switch before you need it

Every bot needs a way to stop trading immediately, without SSH access being the only lever. The simplest version is a file the bot checks each loop:

from pathlib import Path

HALT_FILE = Path("/etc/trading-bot/HALT")

def should_halt() -> bool:
    return HALT_FILE.exists()

When should_halt() is true, the bot should cancel open orders it's responsible for, stop placing new ones, log that it halted and why, and exit cleanly with status 0. That last detail is why Restart=on-failure from Step 2 matters: a clean exit is not a failure, so systemd leaves the service stopped instead of bringing it straight back up mid-halt. With Restart=always the kill switch would look like it worked for about five seconds.

Test this on a schedule, not just once after you write it: sudo touch /etc/trading-bot/HALT, watch the bot log its halt and exit, confirm with systemctl status that it's inactive and staying that way, then remove the file and start it again. A kill switch you've never triggered is a theory, not a control. Do this after every deploy that touches the shutdown path — that code is the least exercised by normal operation.

Back up /etc/trading-bot and the bot's own data directory the same way you'd back up anything else that would hurt to lose — back up your VPS covers what that involves on our machines. A kill switch and a key file are both small, and both are exactly what people forget when "backup" means only the code in git.

On overnight.host

Full disclosure: this is what we sell. A 1 GiB Starter runs a single Python bot process comfortably around the clock; move up a tier once you're running several bots at once, logging heavily, or keeping a local database of fills.

Order vps-starter → · Linux KVM VPS overview

FAQ

How much RAM does a trading bot actually need?

Comfortably under 300 MB for a single bot holding one exchange connection and a modest amount of in-memory state. A 1 GiB VPS covers that with room for the OS and chrony; multiple bots or a growing local database is what pushes you to size up, not the baseline footprint.

Does NAT IPv4 matter for a trading bot?

No, as long as the bot only makes outbound calls to the exchange's REST and websocket endpoints, which is how virtually every exchange API works. NAT and forwarded ports only matter for services that accept inbound connections, and a trading bot doesn't.

Why use chrony instead of the default time sync?

systemd-timesyncd is fine for general use, but chrony tracks and corrects drift more tightly and gives you chronyc tracking to verify the offset. Exchanges that sign requests with a timestamp and a tolerance window reject calls from a clock that's drifted, and that failure looks like a bot bug until you check the clock.

Why did my kill switch stop working after I changed the restart policy?

Almost always because the unit is set to Restart=always instead of Restart=on-failure. Restart=always restarts on any exit, including a clean, deliberate one, so a kill switch that exits with status 0 gets undone within seconds. Restart=on-failure only restarts on a non-zero exit: crashes recover on their own, deliberate halts stay halted.

Is this guide going to tell me what strategy to run?

No. This is entirely about keeping a bot you've already built running reliably and safely on a server — restart behaviour, credentials, clock sync, logging, and a kill switch. What the bot decides to trade, and whether it should, is a decision for you to make with your own risk tolerance, not something to take from a hosting guide.

Written by the person who runs overnight.host: a small, honest hosting company on dedicated bare metal — Linux VPS, game servers, web hosting. Live status at up.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.

DEV Community: overnight.host

Self-hosting WordPress on a VPS: Docker Compose, HTTPS, and the redirect loop nobody explains

The compose file

HTTPS behind Caddy, and the redirect loop

The upload limit nobody remembers

Read this before you buy: the NAT catch for 443

Security basics that matter more than any plugin

Backups: the volume and the database

Updates: bump the tag, let WordPress do the rest

Sizing

On overnight.host

FAQ

Docker Compose on a 1 GiB VPS: what actually fits, and how to keep it up

Install Docker Engine, not docker.io

Add a swap file before you add containers

Read this before you buy: the NAT IPv4 catch

Give every service a memory limit

Log rotation, or the disk fills quietly

Pin every image tag

HTTPS with Caddy, for the services that need it

Pruning: the cleanup that isn't automatic

What actually fits in 1 GiB, and what does not

On overnight.host

FAQ

A self-hosted CI runner on your own VPS: faster builds, and the one rule you must not break

The rule: never on a public repository

What to size it at

Step 1: the machine and a non-root user

Step 2: GitHub Actions runner

Step 3: make it ephemeral if you can

Step 4: GitLab, if that is where you live

Step 5: stop it filling the disk

Step 6: secrets

On overnight.host

FAQ

Self-hosting code-server on a VPS: the honest RAM math, Caddy HTTPS, and the Open VSX catch

What this is actually for, and what it isn't

Installing code-server

Running it as yourself, not as root

The config file: bind-addr, auth, and what auth: none really means

HTTPS with Caddy — a browser IDE has no business on plain HTTP

An IDE on the internet is a shell on your VPS

Extensions come from Open VSX, not the Microsoft marketplace

Workspaces, and git over your dedicated SSH port

Backups and updates

On overnight.host

FAQ

Self-hosting Gitea on a VPS: SQLite vs Postgres, HTTPS, and the SSH port nobody warns you about

SQLite or Postgres, and when it actually matters

Sizing: 1 GiB alone, 2 GiB once Actions run

The compose file

HTTPS with Caddy

Read this before you buy: the SSH port story

Gitea Actions, and where the runner should live

Backups with gitea dump

Updates

On overnight.host

FAQ

Your own WireGuard VPN on a VPS: the NAT port has to match

What WireGuard actually is

Read this before you buy: the NAT IPv4 port catch

Step 1: a clean machine

Step 2: install WireGuard and generate keys

Step 3: the server config, routing and NAT

Step 4: firewall, and the port that has to match

Step 5: one client config

Keeping it running

What a VPN in Dallas or Charlotte does and does not hide

On overnight.host

FAQ

Self-hosting Nextcloud properly: storage, cron, and the settings everyone gets wrong

Decide the shape first

Sizing: it is a disk problem, not a CPU problem

The compose file

The four settings everyone gets wrong

HTTPS and the proxy

After the install: run the checks

Backups

On overnight.host

FAQ

The config file: bind-addr, auth, and what `auth: none` really means