Questionswe get asked

Yes. Every product is built for both: an AMI on AWS, and an Azure Compute Gallery image version on Azure. The software stack, the first-boot credential model and the documented security posture are identical across the two — that parity is the point, so a workload can move between clouds without a different security story. Each product page shows which clouds its image is published on today.

Only the cloud-native parts. On AWS you get an AMI ID, EC2 instance type recommendations, an EBS volume type, and regions like us-east-1. On Azure you get a Compute Gallery image ID (with its resource group, gallery, and image definition), VM size recommendations, a managed disk type, and regions like eastus. Each catalog page shows the fields that apply to that cloud and hides the ones that do not.

Built separately, from the same clean-room recipe. We do not convert or lift-and-shift a disk image between clouds — each is built natively on the cloud vendor’s own official Ubuntu image so it carries the right guest agent, the right instance-metadata integration and the right boot configuration for its platform.

The software versions track together, but release dates can differ by a few days because each cloud has its own publishing and replication step. Always check the release date on the specific image page rather than assuming parity on a given day.

Google Cloud is next: every product is on the roadmap for Compute Engine images with the same build and credential model. On-premises is not planned. If you need GCP, tell us which images matter to you, because that is how the order gets decided.

A pre-built machine image for your cloud — an AMI on AWS or a Compute Gallery image version on Azure — with the software stack installed, configured and verified, plus the documentation around it: the full list of installed software with versions, the written security posture, and step-by-step launch instructions. You launch it like any other image.

On AWS, public images are launchable directly by AMI ID, and private images are shared to the AWS account IDs you give us so they appear under "Private images". On Azure, images are shared from our Compute Gallery to your subscription or tenant. Either way they show up in your console and in your Terraform data sources.

No credential ships in any image. Admin, database and console passwords are generated on your instance at first boot from instance metadata, and the scripts that set them delete themselves afterwards. The getting-started steps on each product page tell you exactly where to find the initial credential and how to change it. SSH is key-only, with root login refused.

No. There is no runtime agent, no sidecar, and no control plane to adopt. If we disappeared tomorrow, the images you already launched would keep running unchanged.

Yes. Contact us with your base OS, required packages and any constraints, and we will tell you honestly whether it is a good fit. Custom builds go through the same clean-room pipeline, with the same first-boot credential model and the same documentation.

Every image in the catalog today bundles open-source software that needs no licence key, and each catalog entry names the licence of the software it ships (MIT, Apache-2.0, AGPL-3.0, and so on). You pay your cloud provider for the compute and storage the instance uses. Where a product also offers a commercial edition, we ship the community edition and say so.

No. Because an image is a static artefact, anything you have already launched keeps working whether or not you stay with us — you would simply stop receiving new revisions.

Not under standard terms. If you are an MSP or platform vendor who wants to embed our images in your own product, contact us and we will work out a redistribution agreement.

Each image lists the regions it is published in on its catalog page, in that cloud’s own naming (us-east-1 on AWS, eastus on Azure). Copying an image to another region is routine work and included — tell us where you run and we replicate it there.

Tell us. Copying an existing image into a new region is a standard step in our pipeline, and region requests are fulfilled as part of getting you the image.

Every image in the catalog today is x86_64. arm64 builds — Graviton on AWS, Ampere on Azure — are on the roadmap behind demand. If you need one, tell us which image, and it moves up the queue.

Every image is built clean-room on the cloud vendor’s official Ubuntu LTS image, with every component from its own official repository or release and nothing copied from third-party images. No credential ships in the image; passwords are generated at first boot and the scripts that set them delete themselves. SSH is key-only with root login refused, databases listen on 127.0.0.1 only, and build-time keys, shell history and logs are removed before capture. Each product page states its posture in full, including the one caveat that applies to most images: they are HTTP-only by design, so terminate TLS at a load balancer or add a certificate before exposing them publicly.

We target a published revision within 72 hours of an upstream fix for a critical CVE affecting a shipped package, plus a scheduled monthly roll-up for everything else.

Yes, and you should. Every product page lists the complete pre-installed software with exact versions, the full security posture, and the getting-started steps that tell you which ports to open and which credentials to expect. Nothing is on the image that is not on that page.

No single product does that. A documented, credential-free base image with a full software inventory removes a large and commonly-flagged chunk of the work, but compliance covers your whole organisation, not just your machine images. We give you the inventory and the posture in writing; your auditor still does the rest.