InterServer VPS setup: choose a template without trusting it blindly

Preflight: record what you intend to buy

Use this path for Linux KVM, not Hyper-V Windows or non-root Storage Hosting. Start with a supported blank Ubuntu/Debian image or Docker template 7781. The reviewed marketplace catalog had no n8n or Ollama entry; do not look for a hidden one-click shortcut.

Before login or payment, create a private procurement note:

• workload and slice hypothesis (two slices/4 GB is the later n8n reference starting point);
• monthly total, currency, tax, renewal date and auto-payment setting;
• NYC metro, Dallas or Los Angeles region; public IPv4 and any verified IPv6 allocation;
• exact OS/template/application version and selected control panel/license;
• hostname, intended domain, DNS owner, administrator contact and recovery email;
• transfer-exhaustion answer and support-scope answer for the exact SKU;
• backup eligibility and independent repository destination.

The public order flow may redirect to login. Confirm stock, tax, and final total in your own account, then save the invoice and template selection.

Choose a provisioning route without making it an update mechanism

Template pages advertise cloud-init, random credentials, UFW, fail2ban and automatic security updates. Treat these as claims to verify, not observed state. InterServer’s FAQ says reinstall replaces server contents. Never use reinstall, rebuild or template redeployment to update n8n, Docker, Ollama or WordPress. If an existing host has data, stop and use the discovery/export runbooks first.

Preserve console recovery before changing SSH

Keep the provider account and HTML5/VNC/console recovery route available. The VPS feature page describes panel power/reinstall/DNS/monitor controls; exact current UI may vary. Do not close the console session until a second independent SSH session works.

If the template supplies random credentials, retrieve them through the provider’s documented private channel and immediately store them in your password manager. Never paste them into a ticket, screenshot, shell history or article. Prefer SSH keys; create a new local key if necessary:

# Run on YOUR workstation, not on the VPS.
ssh-keygen -t ed25519 -a 64 -f "$HOME/.ssh/id_ed25519_interserver"
ssh-copy-id -i "$HOME/.ssh/id_ed25519_interserver.pub" root@203.0.113.10
ssh -i "$HOME/.ssh/id_ed25519_interserver" root@203.0.113.10

Replace 203.0.113.10 (documentation-only address) with your allocated IP. Verify the host key through a trusted provider channel when available; do not blindly accept a changed key. If password authentication is the only initial route, use the private credential once and then install the key. Do not put the password in the command line.

First-login inventory: learn the image before changing it

Run these read-only commands as root/sudo and save a redacted copy with your change record:

set -u
printf '%s\n' '== identity ==' 
hostnamectl
cat /etc/os-release
uname -a
printf '%s\n' '== resources =='
nproc
free -h
lsblk -f
df -hT
printf '%s\n' '== network and time =='
ip -brief address
ip route
timedatectl
printf '%s\n' '== provisioning and failures =='
cloud-init status --long 2>/dev/null || true
systemctl --failed --no-pager
printf '%s\n' '== listeners =='
ss -lntup
printf '%s\n' '== container runtime, if installed =='
command -v docker || true
docker version 2>/dev/null || true
docker compose version 2>/dev/null || true

|| true keeps an absent optional tool from hiding the rest of the inventory; it does not make a failed required service healthy. Record any failed unit and public listener. A Docker page does not prove the Compose plugin is installed or that /opt/aixvps exists.

Look for the actual application configuration without dumping secrets:

systemctl list-unit-files --type=service --no-pager
find /etc /opt /srv -maxdepth 3 \
  \( -name 'compose.yml' -o -name 'compose.yaml' -o -name 'docker-compose.yml' \) \
  -print 2>/dev/null

Do not cat .env, credentials, private keys or random-password files into a shared terminal. List paths and ownership first; inspect secrets only in a protected local session.

Create a named administrator and verify a second session

Choose a unique username and a strong password only if sudo requires it. The following creates ops; replace it if your organization uses another account:

adduser ops
usermod -aG sudo ops
install -d -m 700 -o ops -g ops /home/ops/.ssh
# Create this file with your EDITOR and paste only your PUBLIC key.
nano /home/ops/.ssh/authorized_keys
chown ops:ops /home/ops/.ssh/authorized_keys
chmod 600 /home/ops/.ssh/authorized_keys

From a new workstation terminal, prove ssh ops@YOUR_IP works and sudo -v succeeds. Keep the original console/root session open. Only then consider disabling root/password SSH. Debian/Ubuntu commonly use the ssh unit while some distributions use sshd; discover first:

systemctl list-unit-files 'ssh.service' 'sshd.service' --no-pager
sudo sshd -T | grep -E '^(permitrootlogin|passwordauthentication|pubkeyauthentication) '

Use a drop-in appropriate to the discovered distribution, then validate with sshd -t and reload the correct unit. Do not copy a firewall or SSH policy that locks out your only working session. Keep VNC recovery available until after a reboot test.

Verify firewall, fail2ban and update claims

Inspect rather than assume:

command -v ufw && sudo ufw status verbose
sudo nft list ruleset
systemctl is-enabled fail2ban 2>/dev/null || true
systemctl is-active fail2ban 2>/dev/null || true
sudo fail2ban-client status 2>/dev/null || true
systemctl is-enabled unattended-upgrades 2>/dev/null || true
systemctl is-active unattended-upgrades 2>/dev/null || true

If UFW is already active with required rules, do not reset it. If it is installed but inactive and you have console access plus a working second SSH session, an editorial starting policy is:

# Replace 22 if sshd -T confirms a different effective port.
sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw enable
sudo ufw status numbered

This does not open Postgres 5432, n8n 5678 or Ollama 11434. Keep those private. A provider-side firewall, if your account has one, must agree with host rules; do not assume both exist. fail2ban does not replace key authentication, patching or application access control.

Review unattended-upgrades configuration and reboot policy. Automatic security updates can still require a planned reboot and do not automatically update container images.

Addressing, DNS and TLS gates

Some panel deployments benefit from static addressing, but InterServer’s example nmcli commands contain example interfaces, IPs and gateways. Do not paste them. Use the address, prefix, gateway and DNS values shown by your actual account and ip output, and keep VNC open while changing networking. If the current DHCP/reservation arrangement works, do not change it without a documented requirement.

At your DNS provider:

1. Create the intended A record only after confirming the public IPv4.
2. Create AAAA only if IPv6 is actually allocated and the service is reachable over it. Remove an incorrect AAAA rather than leaving intermittent TLS failures.
3. Keep n8n’s canonical hostname stable. Do not expose database/model ports merely because DNS resolves.
4. Verify public resolution from another network with dig A automation.example.com and dig AAAA automation.example.com.

Caddy in the later reference stack needs public TCP 80/443 for normal certificate issuance/HTTPS. Do not run its container until DNS points to this VPS and no other service owns those ports. No DNS or Cloudflare changes were made by AiXVPS.

Updates and reboot: only for the supported OS you discovered

First take a manual rollback point where eligible and ensure you have an independent backup for anything non-disposable. The provider’s KVM manual backup path has account-specific limits; it is not a substitute for application export.

For a supported apt-based image whose vendor/template documentation permits normal OS package updates:

sudo apt update
sudo apt full-upgrade
if [ -f /var/run/reboot-required ]; then
  printf '%s\n' 'Reboot required; schedule it with console access available.'
fi

Do not run this blindly on a custom application appliance or a distribution using another package manager. Confirm third-party repositories and application compatibility first. Schedule the reboot; afterwards repeat systemctl --failed, ss -lntup, df -hT, free -h and your SSH checks. Package updates do not update pinned containers and must never trigger a template rebuild.

Prepare host readiness for n8n without splitting the installation

The complete installation belongs in n8n operations. Here, establish only prerequisites:

docker version
docker compose version
docker info --format '{{.ServerVersion}}'
df -h /var/lib/docker /opt
timedatectl
ss -lnt '( sport = :80 or sport = :443 or sport = :5432 or sport = :5678 or sport = :11434 )'

If Docker or Compose is absent, follow the current Docker Engine Ubuntu documentation or the documentation for your discovered OS; do not pipe an unreviewed remote script into a shell. If port 80/443 is occupied, identify the owner before choosing a proxy. If 5432/5678/11434 is listening on a public address, stop and restrict it.

Acceptance checklist and troubleshooting

A fresh host is ready only when you have recorded:

• exact product, slices, region, IP and template/application versions;
• working named-admin SSH in a second session and preserved console recovery;
• effective SSH/firewall/fail2ban/update configuration, not marketing labels;
• no unexpected public listener or failed critical systemd unit;
• accurate DNS with no invalid AAAA;
• enough RAM/disk for the intended workload and export;
• rollback point and independent backup destination;
• private credentials in a password manager, not the change log.

SSH timeout: check public IP, provider power state, both firewall layers and route. Key rejected: verify public-key contents/ownership/modes and effective sshd -T; use VNC, not repeated lockouts. No Compose plugin: install via official OS-specific docs. Disk full: identify files before deleting; never prune volumes as a first response. Wrong template: stop before adding data, export anything needed, then make a deliberate destructive decision.

Continue to AI app selection or the complete custom n8n reference deployment. Before relying on the host long term, complete billing, backup and restore validation.