VPS Linux Ubuntu

Check your Ubuntu image choice

Match the intended image to your application, then record what you receive. Leave an answer unknown when you do not have evidence. This check uses published labels and your answers; it does not connect to a server or estimate application capacity.

Choose Ubuntu 22.04, 24.04 or 26.04 for your VPS

Ubuntu is the operating system; the VPS supplies hosting resources and access. Choose a compatible image first, then use the hosting comparison to check resources and costs. This page focuses on OS and application compatibility.

These dates describe standard Ubuntu security maintenance, not every installed package. Ubuntu Pro coverage, third-party repositories and container images need separate checks. A supported release is necessary for many deployments, but does not establish application compatibility.

A plain Ubuntu image and an application template are different choices

The public VDSina Standard catalogue lists the choices below. These are provider labels, checked on 12 October 2026. Confirm the exact build, architecture and regional availability in the order form.

A control panel is not a graphical desktop, and a container image is not the VPS operating-system image. Need an application-specific route? Use the application image selector. Need a first SSH and HTTPS setup? Use the deployment route check.

Check the CPU variant as well as amd64 or arm64

amd64 and arm64 identify different architectures. They do not establish all required CPU features. Ubuntu’s amd64v3 variant targets the x86-64-v3 instruction level.

Starting with Ubuntu 26.04, Canonical publishes amd64v3 variants. Generic Ubuntu Download images include both legacy amd64 and amd64v3 variants; Canonical’s official images for public cloud platforms use v3-enabled builds under the amd64 name. A provider’s Ubuntu 26.04 label does not identify which image it supplies.

For the exact provider image, ask which variant is supplied and whether the virtual CPU exposes the required instructions. uname -m or a visible AVX2 flag alone is not a complete compatibility test. The provider’s public Ubuntu label does not verify that combination.

Keep unconfirmed compatibility open: verify the image requirements and guest CPU together before migration. An architecture label, a recent physical CPU or an SSH login is not proof that every application binary will work.

Check what changes in the application stack

These are the default component series documented for each Ubuntu release, checked on 12 October 2026. They are not the currently installed versions in a provider template. Security revisions can change without changing the series.

Check your dependency lock files, native extensions, PHP modules and database driver against the intended series. A panel can supply its own packages; a PPA has its own release coverage; a container tag has its own userspace. None of those is determined solely by the host’s Ubuntu version.

Identify the image you received

Run these read-only commands inside the VPS. They identify the distribution, running kernel, package architecture and machine architecture. Keep the results with your deployment notes before installing more software.

cat /etc/os-release
uname -r
dpkg --print-architecture
uname -m

Scroll sideways to see the full table →

The kernel string alone does not identify the Ubuntu release or its support coverage. Providers can use cloud-specific kernels. An amd64-only binary should not be assumed to run natively on arm64; confirm an Arm build or explicitly supported alternative before committing.

Check how the image was provisioned

Many images use cloud-init to install keys, create accounts and configure networking. Check whether it exists before requesting its status. Absence alone is not a fault: determine how your provider provisions that image.

if command -v cloud-init >/dev/null 2>&1; then
    cloud-init status --long
else
    printf '%s\n' 'cloud-init is not installed; check the provider provisioning method.'
fi

A running state means setup is still in progress. An error or degraded state needs investigation even if SSH works. When cloud-init is present, examine the relevant logs:

sudo tail -n 50 /var/log/cloud-init.log
sudo tail -n 50 /var/log/cloud-init-output.log

Initialization scripts can print sensitive values; redact logs before sharing. Do not run cloud-init clean or replace network files just to hide an error. Completed provisioning also does not prove an application, database or backup job is healthy; check these separately.

Inspect package candidates before installation

The versioned package names below are Ubuntu 24.04 examples. On another release, inspect that release’s package names and your application’s requirements; a missing 24.04 package name alone does not mean the new image is broken.

Refresh metadata, then inspect candidates for the components you intend to use. The update command refreshes the index without installing these application packages. Record candidate versions and the repositories offering them.

sudo apt update
apt-cache policy python3 php postgresql
apt-cache policy python3.12 php8.3 postgresql-16

An Installed: (none) line means the package is absent. A candidate of (none) means your package sources do not currently offer it. First check names, architecture and configured Ubuntu components rather than adding an arbitrary repository.

Metapackages such as php and postgresql select a default implementation; inspect the versioned package too. For installed software, check the actual executable or running service. python3 --version and php --version identify those executables; a database server can differ from its client tools.

Work through a compatibility decision

Suppose an application supports only Python 3.10 and supplies a native extension only for amd64. These are hypothetical requirements, not a claim about a named product. A default Ubuntu 24.04 arm64 image fails two checks: default Python is 3.12 and the extension targets another architecture.

Changing to amd64 addresses architecture but does not change default Python. A virtual environment isolates packages using the interpreter that created it; it does not turn Python 3.12 into 3.10. Do not replace Ubuntu's system Python to satisfy the application.

Options include upgrading the application or choosing a separately maintained runtime/container with a documented support plan. Confirm all native components support the target platform. An older Ubuntu release has its own remaining maintenance window and is not an automatic fix.

For acceptance, exercise the extension's code path, a database operation, a background job and a backup/restore cycle in staging. Record versions and the application build. Successful installation or a passing home-page request is too narrow to establish compatibility.

Keep containers and package support in the plan

Containers separate application dependencies from Ubuntu's default packages while relying on the host kernel, storage and networking. Check for a supported image build for your platform. Emulation changes performance and support assumptions; do not silently substitute it for a native build.

Persist data in documented volumes or external storage and practise restoring it independently of disposable containers. Pin releases or image digests for reproducibility while scheduling updates. A permanently pinned vulnerable image is reproducible but poorly maintained.

Distinguish Ubuntu release support from coverage of each installed package. Standard security maintenance and Ubuntu Pro have different coverage. Third-party repositories, downloaded binaries and container images have their own maintainers. Record who updates each layer instead of assuming the Ubuntu version covers everything.

Separate routine updates from release upgrades

Inspect pending packages and failed services before changes. These commands list information without performing a distribution upgrade. Refresh package metadata first.

apt list --upgradable
systemctl --failed
if [ -f /var/run/reboot-required ]; then cat /var/run/reboot-required; fi

Review and apply package updates in a suitable window, then repeat application checks. Services may restart during maintenance. The reboot marker is useful when present; its absence does not prove every component is current.

Test a release upgrade on a copy or newly provisioned machine. Recheck runtimes, repositories, database upgrade requirements and extensions. Plan final data synchronization and a route back that accounts for writes after the change. A pre-upgrade snapshot cannot contain later customer orders.

Turn a check result into a next step

The identity commands above describe the guest, not the application binary or container you intend to run. If Docker with the Buildx plugin is already available, replace YOUR_IMAGE:YOUR_TAG with the actual image reference. This registry lookup needs network access and may require your own registry login; never paste credentials into this website.

docker buildx imagetools inspect YOUR_IMAGE:YOUR_TAG

For an image already present locally, replace LOCAL_IMAGE with its name or digest:

docker image inspect --format '{{.Os}}/{{.Architecture}}' LOCAL_IMAGE

Compare the required linux/amd64 or linux/arm64 platform with the intended guest. An OCI index can also contain unknown/unknown attestations; these are not application platforms. An inaccessible registry or missing plugin means the check is incomplete. A matching platform still leaves CPU instructions, extensions and kernel requirements to check. Emulation is a separate route, not a performance guarantee.

The original apt update example refreshes local package indexes and uses the network; it is not a read-only inventory command. Log excerpts may contain secrets. Keep raw provisioning data private and share only a redacted error when requesting help.

Update, upgrade or move to a new image?

Before an in-place upgrade, confirm console access, a supported source release, free disk space, third-party repositories and held packages. Third-party repositories can be disabled during the upgrade; do not blindly re-enable entries for the old release.

do-release-upgrade -c checks for an offered upgrade and can contact release metadata; it does not perform the upgrade. “No new release found” can reflect upgrade availability, release policy or the current system state. Do not add -d merely to force a production upgrade.

For a separate destination, restore the application and a consistent database, check a required request and background job, then plan the final data sync and traffic switch. Decide how to handle new writes if you roll back: changing DNS back does not return those writes to the old database.

Prepare application and database recovery →

Check published software support against the provider template

Docker Engine and HestiaCP documentation currently list Ubuntu 22.04, 24.04 and 26.04. Hestia requires a fresh OS and supports 64-bit AMD64 and ARM64. Its recommended memory is 4 GB; the 1 GB minimum excludes SpamAssassin and ClamAV. A minimum installation requirement is not application capacity.

This upstream support does not change the provider’s Hestia template label of Ubuntu 22. For a newer supported OS, confirm a clean-image installation route instead of assuming the ready-made template uses it. Do not install a clean-OS panel recipe over an existing production stack.

We checked the published requirements; we have not installed or load-tested every OS, architecture and application combination.

Compare what you selected with what was delivered

Use the image check above to save the expected and observed values, open questions and next steps as TXT or JSON. A successful login is only one check; leave missing evidence marked unconfirmed. Keep the exact provider image ID and your private recovery record alongside that download.

If a check fails: keep the working service and its data in place. Investigate an unexpected image with the provider, choose a supported application build, or test a separate destination. Do not erase the current disk to experiment with another image.

Plan a backup and restore check →

Ubuntu Linux VPS questions

Scope and documentation

Release and image choices checked on 12 October 2026 against Canonical’s lifecycle, architecture documentation and 26.04 release notes; Docker Engine Ubuntu requirements; Hestia installation requirements; and the provider’s Standard image catalogue. Component series come from Canonical’s 22.04, 24.04 and 26.04 release notes. Identity and package examples use Ubuntu 24.04 documentation, cloud-init status, dpkg, Python environments and Ubuntu package management; container checks use Docker’s image-inspection documentation. The upgrade and custom-image notes follow Ubuntu’s release-upgrade and image documentation and the provider’s ISO instructions.

The commands are documented checks, not proof that we tested every provider image. Exact image build, CPU exposure, application-template resources and current order availability still require confirmation for your selection.