Provider cluster Operations Updated 2026-11-05

Contabo VPS setup and operations guide

A careful path from Contabo’s order form to a hardened, backed-up VPS—whether you install by hand or start from Contabo’s n8n 1-click image.

Workflow on your VPS — bring Contabo online for real work
How to read this. Steps mirror Contabo’s public panel and help patterns at research time. Labels move—follow the live UI. Pair every click with Contabo’s own documentation when something looks different.

Runbook scope. Examples are illustrative editorial scripts, not official Contabo scripts. Commands assume Bash on Ubuntu/Debian unless a workstation is specified; install the named tools, adapt paths and service names, and review each gate before running. Historical price, storage, and region examples retain the 4 November 2026 research context; this editorial date does not revalidate a checkout quote.

What “setup” means on Contabo

Contabo will hand you a virtual machine with an IP, a root (or image) password, and a Customer Panel row. Everything after that—TLS, firewall defaults, Docker hygiene, model weights, n8n credentials—is yours. That split is Contabo’s product honesty: cheap capacity, customer operations. This guide walks the path as a careful human would walk it on a maintenance window, without pretending Contabo’s UI never changes a label.

You will move through six phases: decide, order, panel literacy, SSH baseline, application bring-up (plain OS or n8n 1-click), then protection (snapshots and Auto Backup). Skip a phase and you usually pay later in restore pain. Read Contabo’s own help articles alongside this page; when they disagree, Contabo wins for button names, and your risk tolerance wins for how strict to be.

If your end state is local AI or automation, skim the sibling articles first so the plan you order is not two sizes too small: Local AI on Contabo and AI automation pipelines. Pricing context lives in the review.

Contabo’s provisioning email is not a ceremony—it is the moment the meter starts and the threat model becomes real. From that minute, brute-force SSH noise will appear in auth logs; scrapers will probe :80; and any 1-click app that published a URL is part of your attack surface. Setup is therefore equal parts installation and refusal: refuse open databases, refuse default passwords that remain default, refuse to postpone snapshots until “after the interesting work.”

Contabo’s price assumes you are the facilities team: you bring hardening, backups, and the habit of snapshotting before risky changes.

Finally, keep a single plain-text runbook in your password manager secure notes: IP, panel URL, SSH user, snapshot last date, Auto Backup yes/no, n8n URL, model disk path, and the Contabo ticket ID of any open issue. When Contabo support asks for the IP and a confirmation phrase for data loss on cancel, you will already have the IP handy—and you will pause before typing confirmation.

Decide before the configurator

Write four lines in a note you will keep with the invoice:

  1. Job statement — e.g. “n8n webhooks + light Postgres” or “Ollama 14B-class models for private chat” or “WordPress + staging.” Mixed jobs need mixed resources or a split-box plan.
  2. Region — EU Hub (Lauterbourg) for Contabo’s base price board and EU-leaning residency; Portsmouth, Carlstadt/NJ–NY, St. Louis, Seattle, Singapore, Tokyo, Mumbai area, or Sydney when users or counsel demand it. Non-EU regions add location fees—budget them.
  3. Tier family — Core Cloud VPS for value RAM; Performance when Contabo’s docs say your workload wants newer CPU/NVMe emphasis; GPU VPS only after you open Contabo’s GPU page and accept the fixed high monthly rate and limited regions.
  4. Recovery bar — “snapshot before every upgrade” is minimum; “Auto Backup + monthly off-site export” is deliberate.

Also decide identity hygiene: one Contabo login for the company, hardware key or strong unique password, and a separate SSH key per operator. Shared root passwords in group chats are how VPS stories become incident reports.

Capacity heuristics (not Contabo promises): n8n alone is often comfortable from ~8 GB RAM upward once you add monitoring headroom; Contabo’s own n8n help recommends more RAM than the absolute minimum. Local models need disk for weights (M) plus reserve (R) for OS, layers, and logs. Treat KV-cache as RAM/VRAM, not disk. Disk reserve covers weights, layers, and logs; see Local AI. WordPress is usually RAM-light compared with models but backup-heavy.

Order flow, step by step

Open Contabo’s VPS catalog (contabo.com/en/vps/ or your locale). The site presents plan cards with vCPU, RAM, storage options, snapshot counts, port speeds, and unlimited traffic footnotes.

  1. Select the plan. Toggle term length and VAT display until you understand both sticker and effective monthly figures. Contabo often highlights long-term effective rates (for example 24-month patterns on EU pages). Monthly Cloud VPS 4 may show a setup fee—Contabo states setup can apply on new VPS 4 monthly contracts and be waived on longer terms. Read the fine print under the card you click.
  2. Choose location. Watch the price summary. If Singapore is out of stock that day, Contabo may say so—do not design a launch around empty stock.
  3. Storage path. Where Contabo offers SSD vs NVMe at the same tier, prefer NVMe for Docker-heavy and model-heavy disks unless you have a reason not to.
  4. Image / application. Clean Ubuntu/Debian for maximum clarity, or Contabo’s n8n 1-click if you want Docker, Caddy, and Let’s Encrypt wired for you. Contabo also lists other 1-click apps; only pick what you will maintain.
  5. Password. Contabo’s n8n help notes the order password is reused for the application. Generate it; store it; do not recycle your email password.
  6. Account and payment. New customers complete personal data and payment. Contabo accepts multiple methods depending on currency; for several methods the first post-order payment is manual using on-screen details, then panel automation becomes available. Returning customers simply authenticate.
  7. Order & Pay. Wait for email. Keep the message with IP and credentials. If you ordered a 1-click app, wait for Contabo’s stated install window (n8n help mentions up to ~30 minutes) before declaring failure.

Photograph or PDF the confirmation. When a location fee or setup fee appears later on an invoice, you want evidence of what the cart showed.

A note on currencies: Contabo presents EUR, USD, and GBP paths with method lists that differ. Corporate cards, PayPal, and bank transfers each have failure modes (3-D Secure loops, holds, slow SEPA). If your first payment is manual, set a timer to complete it; unpaid orders do not become working SSH endpoints by optimism.

A note on Windows: Contabo offers Windows as a paid add-on path on relevant products. This guide assumes Linux because AiXVPS scenarios center on Docker, n8n, and local model tooling. If you need Windows, budget the license line in the cost calculator and expect RDP hardening instead of SSH-only habits.

A note on custom images: Contabo supports custom ISO/qcow2 style deploys for advanced users. That power is excellent for golden images and terrible for first-time buyers who have not yet survived a failed boot. Master Contabo’s stock Ubuntu image once before you bring your own.

Customer Panel literacy

The Customer Panel is Contabo’s real console. SSH is the primary admin path on Contabo; the panel is how you snapshot, cancel, reinstall, and sometimes open a web console when you lock yourself out.

Find Servers & Hosting, open VPS, and study one row: status, IP, OS, the More button. Behind More you will typically find snapshot creation, cancel, and other lifecycle actions. Open the detailed view for credentials reminders and, for 1-click apps, Quick Action logos once installation finishes.

Billing lives elsewhere in the panel: payment methods, invoices, auto-pay toggles. Contabo’s cancel and refund articles assume you can find the service row and the support ticket form. Spend a calm ten minutes mapping those screens the day you buy—not the day a renewal posts.

If Contabo offers account-level two-factor authentication for your account type, enable it before you park production workflows on the box.

SSH, users, and baseline hardening

This sequence assumes a fresh Ubuntu/Debian VPS with OpenSSH, a working root or sudo session, and a separate workstation with OpenSSH tools. Keep the original session open. First open Contabo's panel console/VNC or rescue instructions and verify you can authenticate independently of SSH. Confirm the host-key fingerprint through that trusted console before accepting it on your workstation.

Workstation, Bash: create a dedicated, passphrase-protected key; choose an unused filename and never copy its private half to the VPS.

test ! -e "$HOME/.ssh/contabo_ops" || exit 1
ssh-keygen -t ed25519 -a 64 -f "$HOME/.ssh/contabo_ops"
# Adapt server address and the existing SSH port.
ssh -p 22 root@YOUR.SERVER.IP

VPS, original root/sudo session: install sudo if absent, create a new account with a strong local password for sudo, and keep that password in your vault. Stop if ops already exists; review its ownership instead of replacing files.

set -euo pipefail
sudo apt-get update
sudo apt-get install -y sudo openssh-server
if id ops >/dev/null 2>&1; then
  echo 'ops already exists; inspect it before proceeding' >&2
  exit 1
fi
sudo adduser ops
sudo usermod -aG sudo ops
sudo install -d -m 700 -o ops -g ops /home/ops/.ssh

Workstation: send only the public key through the original administrative login. If that login is a sudo user, transfer to its home first and install it using sudo in the original session. The following root path creates only the new account's authorized keys.

set -euo pipefail
scp -P 22 "$HOME/.ssh/contabo_ops.pub" root@YOUR.SERVER.IP:/home/ops/.ssh/authorized_keys
ssh -p 22 root@YOUR.SERVER.IP   'chown ops:ops /home/ops/.ssh/authorized_keys && chmod 600 /home/ops/.ssh/authorized_keys'
# Open a SECOND terminal/session; force the key, with no password fallback.
ssh -p 22 -i "$HOME/.ssh/contabo_ops"   -o IdentitiesOnly=yes -o PasswordAuthentication=no   -o KbdInteractiveAuthentication=no ops@YOUR.SERVER.IP

VPS, second key session: run sudo -v && sudo id -u. It must succeed and print 0. Only after this key login and sudo test may you disable password/root SSH access. This disables SSH password authentication, not the local password sudo uses. Preserve both sessions.

VPS, verified sudo session: inspect configuration precedence first. Ubuntu/Debian normally include sshd_config.d; first obtained values and later Match blocks matter. Do not assume a late-numbered drop-in overrides cloud-image settings.

set -euo pipefail
sudo grep -nE '^[[:space:]]*(Include|Match|PasswordAuthentication|PermitRootLogin|KbdInteractiveAuthentication)' /etc/ssh/sshd_config
sudo ls -l /etc/ssh/sshd_config.d/
sudo test ! -e /etc/ssh/sshd_config.d/00-local-key-only.conf
sudo test ! -e /etc/ssh/sshd_config.before-key-only
sudo cp -a /etc/ssh/sshd_config /etc/ssh/sshd_config.before-key-only
sudo tee /etc/ssh/sshd_config.d/00-local-key-only.conf >/dev/null <<'SSHCONF'
PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin no
SSHCONF
sudo /usr/sbin/sshd -t
: "${SSH_CONNECTION:?Run inside the verified SSH session}"
ADMIN_IP=$(printf '%s\n' "$SSH_CONNECTION" | awk '{print $1}')
SERVER_IP=$(printf '%s\n' "$SSH_CONNECTION" | awk '{print $3}')
SSH_PORT=$(printf '%s\n' "$SSH_CONNECTION" | awk '{print $4}')
for ACCOUNT in ops root; do
  sudo /usr/sbin/sshd -T -C "user=$ACCOUNT,addr=$ADMIN_IP,laddr=$SERVER_IP,lport=$SSH_PORT"     | grep -E '^(port|pubkeyauthentication|passwordauthentication|kbdinteractiveauthentication|permitrootlogin) '
done

Require effective pubkeyauthentication yes, both password methods no, and permitrootlogin no. If they differ, inspect Includes and Match rules, correct the responsible configuration, and rerun both checks. Do not reload until they match. Then run sudo /usr/sbin/sshd -t && sudo systemctl reload ssh and open another fresh key session with sudo before closing the originals. Keep the existing SSH port through this process.

Recovery: use the still-open session or authenticated panel console to move this new drop-in to /root/00-local-key-only.conf.disabled, restore any separately edited file from its recorded backup, run sshd -t, then reload ssh. If the guest cannot boot, use Contabo's rescue system to mount and repair the installed filesystem; do not reinstall over data. Console passwords remain useful even after root SSH is disabled.

Firewall discipline

Before enabling a firewall, record the actual SSH source and destination port. The example assumes UFW is installed and currently inactive, an SSH session directly from the intended administrator address, and IPv6 filtering enabled in UFW if the VPS has IPv6. A VPN or jump host changes the observed source. Inspect existing rules before modifying an established installation.

In Contabo's panel firewall, allow that source to the actual SSH TCP port first, for each address family you use. Preserve console access. Then apply the matching guest rule from the verified sudo session:

set -euo pipefail
: "${SSH_CONNECTION:?Use the working SSH session}"
ADMIN_IP=$(printf '%s\n' "$SSH_CONNECTION" | awk '{print $1}')
SSH_PORT=$(printf '%s\n' "$SSH_CONNECTION" | awk '{print $4}')
printf 'Allow source %s to SSH TCP port %s\n' "$ADMIN_IP" "$SSH_PORT"
sudo ufw status verbose
sudo ufw allow proto tcp from "$ADMIN_IP" to any port "$SSH_PORT"
sudo ufw default deny incoming
sudo ufw default allow outgoing
# Only when the TLS proxy is prepared and public HTTP(S) is intended:
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw show added
sudo ufw enable
sudo ufw status verbose

Immediately test a fresh key login from the allowed source. If it fails, use the original session or panel console to correct the source/port rule; sudo ufw disable can temporarily recover from a guest rule mistake, but does not change a blocking panel rule. Re-enable after fixing and testing.

Docker published ports can bypass UFW. Bind applications as 127.0.0.1:5678:5678, leave the database unpublished on an internal Compose network, and expose only the authenticated TLS proxy. Review Docker's firewall integration rather than disabling Docker's rules. Check both IPv4 and IPv6 listeners and attempt access from a separate machine; an internal network name is not an ingress policy by itself.

Plain OS application bring-up

If you skipped 1-click apps, install deliberately:

  • Reverse proxy (Caddy or Nginx) with Let’s Encrypt.
  • Docker Engine + Compose plugin from official docs.
  • Your stack: n8n, Postgres, Ollama, Open WebUI, etc.
  • Log rotation and disk alerts (df at 80% is already late for model disks).

Use volumes on a named path you will include in export scripts. Bind-mount secrets carefully; prefer environment files with locked permissions over hardcoding tokens in workflow JSON.

n8n 1-click path in detail

Contabo documents a free n8n add-on: Ubuntu 24.04 LTS, Docker-based, Caddy reverse proxy, Let’s Encrypt certificates. After order, credentials arrive by email; the application password matches the server password you set. Contabo’s help walks Customer Panel → Servers & Hosting → VPS → Quick Action once install completes.

Contabo’s published sizing table for the add-on lists modest minima and higher recommendations (including an 8 GB recommended RAM line). That is your cue to avoid starving n8n on Cloud VPS 4 if you also plan binary nodes or concurrent runs.

Day-two ownership:

  1. Log into n8n; enable ownership features you need; create an owner user if the image bootstrap requires it.
  2. Configure timezone and execution data pruning.
  3. Export a workflow JSON sample to your laptop to prove export works.
  4. Locate Contabo’s documented install path (Contabo’s blog mentions /opt/n8n/ style layouts)—know where Compose lives before you need to rescue it.
  5. Schedule updates; Contabo’s application disclaimer puts ongoing open-source maintenance on you.

When webhooks must face production traffic, put Cloudflare or another edge in front only if your threat model needs it—and remember Contabo fair-use still applies to origin egress.

Inspect an existing installation before changing it. Do not assume the 1-click image uses this article's paths or service names. These VPS commands list metadata only; avoid unrestricted docker inspect, rendered Compose configuration, or printing .env, which can reveal credentials.

docker compose ls
docker ps --format 'table {{.Names}}	{{.Image}}	{{.Ports}}'
# Replace with the n8n container name discovered above.
N8N_CONTAINER='REPLACE_WITH_CONTAINER'
test "$N8N_CONTAINER" != REPLACE_WITH_CONTAINER || exit 1
docker inspect --format '{{ index .Config.Labels "com.docker.compose.project.working_dir" }}' "$N8N_CONTAINER"
docker inspect --format '{{ index .Config.Labels "com.docker.compose.project.config_files" }}' "$N8N_CONTAINER"
docker inspect --format '{{range .Mounts}}{{println .Type .Source .Destination}}{{end}}' "$N8N_CONTAINER"
sudo systemctl status caddy --no-pager || true
sudo ss -lntup

Inspect the discovered Compose files privately, map the database type, mounts, proxy, encryption-key source, and owner login. No Compose labels? Check systemd unit paths and the image's current instructions. Back up before adopting another layout; pointing a populated instance at a new Postgres container does not migrate SQLite.

Workstation TLS verification: substitute your real DNS name; verify DNS points at this VPS, the browser reports a valid chain, and an owner login works. Do not use -k to hide certificate problems.

set -euo pipefail
N8N_HOST='automation.example.com'
test "$N8N_HOST" != automation.example.com || exit 1
curl --fail --silent --show-error --max-time 20   "https://$N8N_HOST/healthz/readiness" >/dev/null
openssl s_client -connect "$N8N_HOST:443" -servername "$N8N_HOST"   -verify_hostname "$N8N_HOST" -verify_return_error </dev/null

Readiness proves database connectivity and migrations, not a working workflow. Run a harmless manual workflow, then an authenticated test webhook with a unique event ID. Confirm the certificate renewal service/timer or proxy automation and verify its next renewal attempt without publishing its logs.

Snapshots: how and when

Contabo help describes snapshots as state captures for Cloud VPS—useful before upgrades, not a substitute for backups. Create via More → Create Snapshot; name with date and intent (2026-11-04-pre-n8n-upgrade). Retention is about 30 days; counts are plan-capped; snapshots are not downloadable.

Take a snapshot when: OS updates land, Docker major versions bump, you migrate databases, or you are about to delete “unused” volumes. Do not snapshot mid-write if you can drain queues first—see the billing article’s pause section.

Auto Backup add-on

Auto Backup (Contabo product pages and docs) adds daily off-server backups with roughly 10 days of retention and whole-disk restore to the same VPS. Restores overwrite; the VPS is down during restore. Enable at order or later if your SKU supports it (Core 4–18 and Performance equivalents per Contabo docs; not universal across GPU/Storage/Dedicated).

Verify a restore on a disposable VPS once. An unchecked backup checkbox is theater. Contabo states it ensures backups run and are accessible but does not guarantee recoverability or perform recovery for you—so your export discipline still matters.

Upgrades and the growth ladder

Treat every Contabo size or product change as a controlled migration—not a silent slider. Contabo’s panel may offer plan-change paths for some SKUs; still use this cluster’s default procedure so IP changes, overlapping invoices, and export discipline stay predictable:

  1. Order the target Contabo VPS (Core, Performance, or Contabo GPU VPS) in the region you need; confirm storage type and price in cart.
  2. Export apps, databases, model weights, and secrets off Contabo (portable dumps you can restore without Contabo’s panel).
  3. Provision, harden, restore, and smoke-test on the new service (SSH, firewall, disk free space, app health).
  4. Update DNS, webhooks, and integrations to the new IP.
  5. Cancel the old Contabo service only after soak tests pass. Budget overlapping Contabo invoice days in the cost calculator.

Read Contabo’s live article for what Contabo currently offers your SKU, then still migrate as above: How to make changes to your VPS or VDS plan (verify live). Region moves and Core→Performance or Contabo GPU VPS moves follow the same order-new / migrate / cancel-old path; disk-type changes (for example SSD to NVMe) erase the old disk unless you exported first.

Growth ladder for AI hosts: move to a larger Contabo plan with the migration checklist above when RAM/CPU is the limit; split n8n and models onto a second VPS when same-box pressure returns; only then consider Contabo GPU VPS if VRAM is the real requirement.

VPS-to-VPS copy sketch: install rsync on both servers, verify the new server's host key, and precreate a writable target directory. This allowlists only application-owned, quiesced artifacts. Keep uploads frozen for the final copy. Never rsync /var/lib/docker, a live Postgres data directory, SQLite files with active writers, or arbitrary volume trees; restore a logical dump instead.

set -euo pipefail
NEW_HOST='REPLACE_WITH_NEW_IP'
test "$NEW_HOST" != REPLACE_WITH_NEW_IP || exit 1
# Adapt this dedicated artifacts path; it must contain no DB volumes or secrets.
rsync -a --dry-run --itemize-changes -e 'ssh -p 22'   /srv/artifacts/ "ops@$NEW_HOST:/srv/artifacts/"
# After reviewing the dry run and stopping artifact writers:
rsync -a --checksum -e 'ssh -p 22'   /srv/artifacts/ "ops@$NEW_HOST:/srv/artifacts/"

Restore DB exports and inject secrets separately over a protected channel. Test staging with outbound side effects blocked; only one production scheduler may run at cutover. Verify new webhooks and credentials, keep old ingress paused during the soak period, and cancel the old service last.

Verify after first boot

On the VPS, establish a baseline before adding models or workflows. These read-only checks require standard Linux tools; kernel logs need sudo. Review locally because logs and listener metadata may reveal internal addresses.

uname -r
uptime
free -h
df -hT / /var/lib
df -ih / /var/lib
lsblk -o NAME,SIZE,FSTYPE,MOUNTPOINTS
ip -brief address
sudo ss -lntup
timedatectl status
systemctl --failed --no-pager
sudo journalctl -k -b -p warning --no-pager -n 60

Compare mounted usable space with the purchased capacity, account for filesystem overhead, and resolve failed services or unexpected public listeners. Confirm NTP synchronization before relying on schedules. If Docker is already installed, also run docker system df and docker stats --no-stream. Do not blindly prune volumes to gain space. Apply OS updates in a maintenance window with recovery access and a backup, then repeat key-login and app readiness checks after any reboot.

Where to go next

Contabo review Local AI on Contabo AI automation Billing, backup, cancel Cost calculator

Sources and updates

Last editorial pass: (America/Los_Angeles, PST).