Choosing an Ubuntu Image for a Cloud Server: A Practical Support Checklist

By UCELI · Prepared with AI assistance · Support dates checked 30 October 2026

A cloud server may offer several Ubuntu images, but choosing the newest-looking entry is only the beginning. The useful question is whether the exact image can run your application and receive the security maintenance you expect for as long as you need it.

For a new deployment, the decision involves four separate checks: application compatibility, the release’s maintenance window, the coverage actually enabled on the machine, and a recovery plan. An image shown in a catalog is not evidence that every package is maintained, that a particular subscription is included, or that the image is available in every location.

This guide explains a practical way to compare options. It is general education, not a claim that UCELI offers every version mentioned or a substitute for checking the provider’s current order page and terms.

Start with the application, not the server menu

Write down the versions your application depends on: the language runtime, web server, database, package manager, libraries and any vendor-supplied agent. Include software installed from third-party repositories, not just packages that come with Ubuntu.

Next, check those projects’ own compatibility information. A newer Ubuntu LTS release can be a sensible candidate for a new application, but it may also introduce a newer runtime or library that needs testing. Conversely, an older version may be necessary for a legacy dependency while the team plans a migration.

Think about the expected service life. A short-lived test machine and an application intended to run for several years have different maintenance needs. If the application will outlive the release’s standard support window, budget time to upgrade or check whether an appropriate extended-maintenance option exists. Treat that decision as part of the deployment plan, not a problem to discover later.

Understand the dates before comparing images

Ubuntu Long Term Support, or LTS, releases have a published standard maintenance period. Canonical offers additional security maintenance through Ubuntu Pro for eligible releases and packages, subject to its terms. Standard maintenance and extended security maintenance are related, but they are not interchangeable: the latter requires the appropriate entitlement and services.

According to Canonical’s release-cycle table, the following LTS dates applied when checked on 30 October 2026:

Release — Standard security maintenance (release-cycle table) — Expanded security maintenance via Ubuntu Pro

Ubuntu 26.04 LTS — May 2031 — May 2036

Ubuntu 24.04 LTS — May 2029 — May 2034

Ubuntu 22.04 LTS — May 2027 — May 2032

Ubuntu 20.04 LTS — May 2025 — May 2030

These are vendor lifecycle dates, not an inventory list for any cloud provider. In particular, listing Ubuntu 26.04 in this table does not mean UCELI currently offers that image. Confirm the actual images for your selected location and configuration before ordering. Canonical documents can differ on the exact end month; for planning, use the earlier date and verify the current terms for the specific service. Dates and terms can change, so check the current vendor documentation when deciding.

Ubuntu 20.04 illustrates why the distinction matters. Its standard support has ended, but Canonical lists an extended coverage period through Ubuntu Pro. That does not mean every existing 20.04 server automatically receives those updates. An operator must check the relevant subscription, enabled services and package coverage. Some older releases have further Legacy add-on options with their own conditions; do not apply the same end date to every release.

Ask what “supported” covers

Standard Ubuntu LTS security maintenance covers packages in the Main repository. Community-maintained Universe packages may also receive best-effort security updates, without the same standard maintenance commitment. The services available through Ubuntu Pro can extend security maintenance to eligible packages, but their scope depends on the subscription, Ubuntu release and enabled service. A technical support contract is another question: access to security maintenance does not automatically mean you have a help desk contract for every operational issue.

Separate these questions when comparing images:

- Is the operating system release within its standard support period?

- Which installed packages are in scope for the maintenance service?

- Are the required extended-maintenance services actually enabled?

- Are the subscription and any additional support suitable for your use?

- Who maintains software installed from external repositories or bundled directly with the application?

The answer may differ for the operating system, an application runtime, a database and a commercial third-party agent. An update to one does not guarantee an update to the others. Likewise, a package that is eligible for security maintenance is not a guarantee that a fix exists for every vulnerability or that installing an update will automatically resolve an application-level problem.

Do not assume Ubuntu Pro or a paid support arrangement is included with a UCELI cloud server. Confirm the specific offering, eligibility and any extra charges with the relevant provider before relying on them.

Check an existing server before planning a move

If you already operate Ubuntu, first identify the release and record the software the application actually uses. On a machine where the Ubuntu Pro client is installed, the read-only command pro status can show whether the machine is attached to a subscription and the state of services.

Read the labels carefully. A service shown as available is not necessarily enabled. A machine’s attachment status also does not prove that every installed package is covered. Compare the output with the relevant vendor documentation and your subscription details. Do not paste subscription tokens, credentials or private server output into a public discussion.

Record external dependencies too: custom packages, a separate database, third-party software repositories and integrations may have their own upgrade requirements. A maintenance plan should identify the owner of each dependency and the source of its updates. If that information is unavailable, mark it as an open question rather than assuming the operating system image covers it.

Compare two choices with a simple worksheet

Suppose a team is preparing a small web application and is considering Ubuntu 22.04 and 24.04. Rather than deciding from the labels alone, fill in the same worksheet for each candidate:

1. Availability: Is the exact image offered for the chosen cloud location and server configuration today?

2. Compatibility: Do the required runtime, database and vendor tools support it?

3. Maintenance: When does standard support end, and what is the plan after that date?

4. Operations: Can the team monitor updates, handle reboots and restore the workload?

5. Cost and terms: If extended maintenance or external support is needed, who provides it and what are its current terms?

This is a hypothetical comparison, not a recommendation that one release fits every workload. The later standard-support date for 24.04 can be useful for planning, but compatibility and actual image availability still need confirmation. If neither candidate meets the application’s requirements, investigate the dependency and migration path rather than selecting a version solely by date.

Plan for updates, upgrades and recovery

Choosing a supported image is a starting point, not the whole maintenance process. Keep an inventory of deployed systems and a way to check pending updates. Decide who applies security updates, how changes are tested, and when reboots can happen. Review the maintenance plan again when dependencies or the server’s expected life change.

For an existing production workload, create and verify a restorable backup before a release upgrade. Test the application and database in a separate environment, including connections to external services and the recovery process. Use Canonical’s documented upgrade path for the versions involved; do not assume that skipping intermediate LTS releases is supported or that a failed upgrade can be reversed without a tested recovery plan.

Also separate an operating-system image from the data it runs. Replacing a server can require restoring application files, secrets, database contents and configuration. Plan how to validate the restored service before redirecting production traffic, and retain a rollback option that matches your actual infrastructure.

Before you place an order

Check the image name and version, the application’s documented requirements, the maintenance period and any subscription conditions. Then review the provider’s current availability, configuration and final order terms. If a required detail is missing, ask before committing rather than treating an unchecked box as an included feature.

For questions about UCELI cloud-server configurations or image availability, contact support@uceli.com.