Andritz VPS: server details

For the migration team. Checked on the live server on 5 October 2026.

Host

ItemValue
Public hostnameandritz.effetechnology.in pointing to 201.18.193.142 (A record only)
IPv62a02:4780:63:774f::1/48 is on the interface but not published in DNS
Provider hostnamesrv1982486, a KVM virtual machine
OSUbuntu 24.04.4 LTS, kernel 6.8.0-139-generic, x86_64
CPU4 vCPU, AMD EPYC 9355P
RAM15 GiB, of which under 1 GiB is in use
Swap4 GiB swap file, swappiness 10
Disk193 GB ext4 on /dev/sda1. 39 GB used, 154 GB free.
TimeUTC, synced with NTP

Access and security

ItemState
SSHssh effeserver@201.18.193.142 on port 22, key login only
SSH settingsRoot login off, password login off, public key login on. Our settings are in /etc/ssh/sshd_config.d/00-hardening.conf, which loads before the cloud-init file. Check any change with sudo sshd -T.
Userseffeserver is the only login user. It is in the sudo and docker groups and has passwordless sudo.
Firewallufw is on. Incoming traffic is blocked except ports 22, 80 and 443 (IPv4 and IPv6).
Open ports22 (SSH), 80 and 443 (Caddy). DNS on 53 listens on localhost only.
Updatesunattended-upgrades is on
TLSLet's Encrypt certificate, renewed by Caddy. Current one expires 15 December 2026.

Application stack

Everything runs in Docker (Engine 29.8.1, Compose v5.5.1). The Compose project is called andritz and lives in /srv/andritz/deployment/current, which is a symlink to the active release, releases/314fa48.

Run Compose commands from that folder as sudo docker compose -p andritz. The folder has a docker-compose.override.yml that sets the API image tag and the WebGL build path, so keep it in place.

ContainerImageWhat it doesPorts
andritz-caddycaddy:2-alpineHTTPS, serves the Unity WebGL build, routes API traffic80, 443 public
andritz-api-primaryandritz-api-primary:314fa48Main Express API. Node 22.23.3 on Debian 12.5000, internal
andritz-api-secondaryandritz-api-secondaryOTP and media API. Node 22.23.2 on Debian 12.3000, internal
andritz-dbmariadb:11.8MariaDB 11.8.93306, internal

All four containers restart automatically (unless-stopped) and none have restarted since they were started.

Caddy routes requests like this:

Docker volumes: andritz_db-data, andritz_caddy-data and andritz_caddy-config. Networks: andritz_edge and andritz_data.

Data to move

WhatWhereSize
Database andritz_dbvolume andritz_db-data15 tables, 0.64 MB
Database userdatavolume andritz_db-data10 tables, 0.28 MB
User uploads/srv/andritz/data, mounted into both APIs at /data5.9 MB
Unity WebGL builds/srv/andritz/web/releases. 29fb756 is live; aed058b and cb7c0c4 are kept for rollback.918 MB for all three
Deployment releases/srv/andritz/deployment/releases (11 releases)5.9 MB
Unity project/srv/andritz/unity-project (Assets, Packages, ProjectSettings)3.3 GB
Unity source archive/srv/andritz/unity-source22 GB
Database backups/srv/andritz/backups208 KB

Database character set is utf8mb4 with utf8mb4_unicode_ci collation.

The Caddy volumes only hold certificates and Caddy state. A new server can get its own certificate, so they don't need to move.

Passwords and keys are in /srv/andritz/deployment/current/.env. We will send them separately.

Scheduled jobs

andritz-backup.timer runs every day at 02:15 UTC. It calls scripts/backup-db.sh, which writes a gzipped dump of each database to /srv/andritz/backups. The latest dumps are from 5 October 2026 and check out: both files are intact and contain all 15 and 10 tables.

Apart from that, only the standard Ubuntu timers run (apt, logrotate, sysstat, fstrim). There are no cron jobs for any user.

Things to sort out

  1. Backups stay on the same disk as the database. Nothing is copied off the server yet, so add offsite storage on the new setup.
  2. There are 27 package updates waiting and the server wants a reboot.
  3. fail2ban isn't running. SSH only takes keys, so the risk is low, but it's cheap to turn on.
  4. Docker has about 3.7 GB of build cache plus a few old images. These can be cleaned up once the current release is signed off.

Sizing

Right now the server is close to idle. Under 1 GiB of RAM is in use, load is near zero, the databases are about 1 MB and uploads are about 6 MB. That is because only a small group of test users is on it.

Plan to scale as the user base grows. The database and the uploads folder grow with every user and every file uploaded, so give them room and keep an eye on disk. Bandwidth will probably be the first real limit. Each first visit downloads the Unity build, which is roughly 300 MB, so the monthly transfer climbs quickly with new users. Add CPU and RAM when the APIs and the database start to show load.

The hosting panel shows the bandwidth allowance. You can't see it from inside the server.

The 25 GB of Unity source and project files only need to move if the new server should also keep a copy of the source.