Skip to content

Elastic VPS Updated 2026-05-27

Elastic VPS use cases

Practical workloads on Stack Harbor PaaS Elastic VPS — a Java console application, a self-hosted mail server, and when to reach for a VPS in general.

This page collects concrete workloads that fit Elastic VPS on Stack Harbor PaaS — workloads where a full VM is a better match than a container. Two are documented in detail: running a Java console application, and self-hosting a mail server inside a CentOS VPS.

Java console application

Some Java workloads are not web applications and have no business running inside an application server. Examples: a long-running command-line process that ingests data from a queue, a scheduled batch job, a CLI integration that talks to vendor APIs and produces files.

For these, the right shape is often a single VPS with a JRE installed, the JAR in place, and a systemd unit or a cron entry that starts the process. You get:

  • A predictable place to put the JAR file and log output (/opt/<app>, /var/log/<app>).
  • Direct access to the OS process — top, ps, jstack, jstat, normal tooling.
  • No application-server overhead.
  • A clean way to schedule with cron or systemd timer units.

The platform’s VPS layer gives you that VM. The pages under Elastic VPS overview cover per-distribution setup (dnf for AlmaLinux / CentOS, apt for Debian / Ubuntu); the rest is standard Linux administration.

Self-hosted mail server inside a VPS

A mail server (Postfix + Dovecot, or an integrated stack like Mailcow or iRedMail) is a workload that is almost never a good fit for a container. It expects:

  • Full control of TCP ports including 25 / 465 / 587 / 993 / 995.
  • A stable public IP address with sensible reverse DNS — a hostname that resolves both ways.
  • File-system persistence for mail spools, indexes, and TLS keys.
  • A long-running daemon set, not a transient process.
  • The ability to run cron-style maintenance jobs (greylisting cleanups, log rotation, certificate renewal).

A CentOS or AlmaLinux VPS with a public IP is the right shape for this. The setup work is the standard mail-server tutorial for the chosen software, with the platform-specific details limited to: configuring the VPS to use the attached public IP, ensuring reverse-DNS records point at it, and making sure the inbound mail ports are not blocked by the platform’s firewall or by the upstream network provider.

A working mail-server stack typically wants:

  • 4 GiB of RAM as a starting point — bump it via the cloudlet dynamic limit.
  • 40 GiB+ of disk depending on the mail volume you expect.
  • Daily off-VPS backups — use the platform’s backup tooling or roll your own to an external store.

Other workloads that fit a VPS

The two cases above are the worked examples. The same logic applies to other workloads:

  • Self-hosted Git server, CI runner, or build farm. Especially when a project needs Docker-in-Docker, kernel modules, or hardware-feature access that a container can’t deliver.
  • Self-hosted VPN concentrator (WireGuard, OpenVPN). Wants kernel modules and full network control.
  • Network simulation or training labs. Wants the freedom to spin up arbitrary network topologies inside the VM.
  • Anything you would normally run on a dedicated Linux box. If your operations runbook starts with “give it a Linux machine and install X”, a VPS lets you keep that runbook unchanged inside the platform.

What doesn’t fit

Standard web applications, REST APIs, background workers, anything that’s already at home in a container — those should stay containerised. The platform’s container types are lighter, scale faster, and play nicer with declarative topologies, auto-clustering, and the rest of the PaaS feature set. The VPS slot is for the workloads where a container is the wrong abstraction, not for everything that happens to run on Linux.

  • Elastic VPS — when to pick a VPS over a container.
  • Elastic VPS overview — the available distributions.
  • Elastic VPS management — configuration and access methods.