AWS Lightsail Alternatives in 2026

AWS Lightsail packages a virtual server, storage, a static IP and data transfer into one monthly price. For a small API, a WordPress site or a side project, it is a simple way to start on AWS.

As a backend grows, Lightsail's limits start to show: instances and container services come in fixed bundles that you resize by moving to a bigger plan, managed databases are a separate set of bundles, and most of the AWS services a growing backend needs, such as SQS, Fargate autoscaling or RDS features, live outside Lightsail. According to the Lightsail pricing page, Linux instances with a public IPv4 address start at $5 per month for 512 MB of memory (IPv6-only bundles start at $3.50), container services at $7 per month, managed databases at $15 per month and load balancers at $18 per month. A setup with a container service, a high availability database and a load balancer already spans several bundles.

Of the alternatives below, Encore, ECS Express Mode, EC2 and Cloud Run run your backend on AWS or Google Cloud, while Render and Fly.io run it on their own platforms, and DigitalOcean, Hetzner and Vultr offer the same VPS model as Lightsail outside AWS.

Lightsail alternatives at a glance

Encore: grow into RDS, SQS and Fargate from your code

Encore combines an open source infrastructure SDK for TypeScript and Go with a platform that provisions and deploys what the code declares into your own AWS or GCP account. Instead of picking bundles, you declare the database, cron jobs, buckets and Pub/Sub topics in the code, and encore run starts the services with a local Postgres next to them.

The Lightsail pieces map onto Encore declarations and the AWS services they become:

An orders database and an hourly job that used to be a crontab line on the instance:

import { api } from "encore.dev/api";
import { SQLDatabase } from "encore.dev/storage/sqldb";
import { CronJob } from "encore.dev/cron";

// RDS on AWS, Cloud SQL on GCP, and a local Postgres under `encore run`.
const db = new SQLDatabase("orders", { migrations: "./migrations" });

// Only touches rows that are still pending, so a repeated run is harmless.
export const expirePending = api(
  { expose: false, method: "POST", path: "/orders/expire-pending" },
  async (): Promise<{ cancelled: number }> => {
    const rows = await db.queryAll<{ id: number }>`
      UPDATE orders SET status = 'cancelled'
      WHERE status = 'pending' AND created_at < now() - interval '24 hours'
      RETURNING id`;
    return { cancelled: rows.length };
  },
);

// Replaces the crontab entry on the Lightsail instance.
const _ = new CronJob("expire-pending", {
  title: "Cancel orders left pending for a day",
  every: "1h",
  endpoint: expirePending,
});

encore run starts the service with a local Postgres. Once you connect your AWS account, a git push deploys the services and creates the database in that account, and Encore provisions an IAM role for the service. The infrastructure docs describe what each declaration becomes on AWS and GCP.

Good to know

Encore supports TypeScript and Go. A PHP or WordPress site on Lightsail stays where it is. Moving the data is a separate step: dump the Lightsail database with pg_dump and restore it into the RDS database Encore created with encore db conn-uri and pg_restore.

ECS Express Mode: one container on AWS

Amazon ECS

ECS Express Mode takes a container image and creates a Fargate service with its own URL, a load balancer with TLS, auto scaling and monitoring. AWS points new customers here because App Runner is closed to new customers. There is no extra charge for Express Mode itself, and you pay for the Fargate tasks, the load balancer, CloudWatch and data transfer it creates.

For a Lightsail container service, this is the closest step up. Instead of picking a fixed node size and count, you give Express Mode a CPU and memory size and a scaling range, and it adds tasks as CPU use rises. Express services that share a network configuration also share an Application Load Balancer, which keeps the cost down when you run several of them. Everything it creates sits in your account, so you can later manage the load balancer, task definition or scaling policy directly.

Per the getting started guide as of November 2026, one CLI call creates the service:

aws ecs create-express-gateway-service \
  --service-name orders-api \
  --primary-container '{"image":"123456789012.dkr.ecr.eu-west-1.amazonaws.com/orders:latest","containerPort":8080}' \
  --execution-role-arn arn:aws:iam::123456789012:role/ecsTaskExecutionRole \
  --infrastructure-role-arn arn:aws:iam::123456789012:role/ecsInfrastructureRoleForExpressServices \
  --health-check-path /health \
  --scaling-target '{"minTaskCount":1,"maxTaskCount":10}' \
  --monitor-resources

You give up the single bill and the bundled transfer allowance that Lightsail has. Express Mode covers stateless HTTP services only, so the database, buckets, schedules and queues are separate resources. An RDS Postgres instance, an EventBridge schedule and an SQS queue each need their own setup, usually in Terraform or CloudFormation, plus the IAM roles above.

Pick it when you run one or two HTTP containers on AWS, the database already exists or is easy to create by hand, and you want autoscaling without writing the ECS and load balancer configuration yourself.

EC2: the same server model with every instance type

Amazon EC2

Lightsail instances run on EC2, and moving to EC2 directly removes the bundle layer. You pick from the full range of instance types, including Graviton, memory optimized and GPU instances, place them in your own VPC with security groups, attach EBS volumes that you size separately from the instance, and put them behind an Application Load Balancer with an Auto Scaling group.

The mental model stays the same as a Lightsail instance: an Ubuntu or Amazon Linux machine you SSH into, with systemd, nginx and a process manager. Per the Lightsail export docs, a Lightsail instance snapshot can be exported to EC2 as an AMI and an EBS snapshot, so you can launch the same server on EC2 without rebuilding it. Launching a server from the CLI looks like this:

aws ec2 run-instances \
  --image-id ami-0abcdef1234567890 \
  --instance-type t4g.small \
  --key-name deploy \
  --security-group-ids sg-0123456789abcdef0 \
  --subnet-id subnet-0123456789abcdef0

What you gain is room to grow: RDS with read replicas and Multi-AZ, S3, SQS and every other service in the same VPC, plus Savings Plans for steady workloads. What you give up is the flat monthly price. Compute, EBS storage, data transfer and, per the VPC pricing page, every public IPv4 address are billed separately on EC2, and outbound transfer that a Lightsail bundle would have included now shows up as its own line.

You also take on the work Lightsail hid: OS patching, the VPC and subnet layout, launch templates, scaling rules and the deploy process to a fleet of servers rather than one.

Pick it when you want to keep running servers, need an instance type or network setup Lightsail does not offer, and have someone on the team comfortable owning VPCs and Auto Scaling groups.

Google Cloud Run: request-driven containers on GCP

Google Cloud Run

Cloud Run runs a container per service and scales instances with incoming requests, down to zero when idle. It is the GCP counterpart to a Lightsail container service, without fixed node sizes: you set CPU, memory, concurrency and the minimum and maximum number of instances per service.

Deploying from source or an image is one command:

gcloud run deploy orders-api \
  --image europe-docker.pkg.dev/my-project/app/orders:latest \
  --region europe-west1 \
  --min-instances 0 --max-instances 20 \
  --set-env-vars DATABASE_URL=...

Request timeouts default to 5 minutes and can be raised to 60 minutes, per the Cloud Run timeout docs. Work that runs longer goes into Cloud Run jobs, which run a container to completion and fit migrations and batch tasks.

The data side is separate. Postgres and MySQL run in Cloud SQL, files go in Cloud Storage, Cloud Scheduler triggers scheduled endpoints and Pub/Sub handles background work. Each is a separate resource with its own configuration and IAM bindings. Scale to zero also means cold starts after idle periods, which you can avoid by setting a minimum instance count and paying for it while it sits idle.

Moving from Lightsail to Cloud Run means moving clouds as well as platforms. Your AWS services, IAM setup and VPC peering stay behind, and the Lightsail database moves to Cloud SQL with pg_dump and pg_restore.

Pick it when the team is already on Google Cloud, traffic is spiky or low most of the day, and the app is stateless HTTP. The Cloud Run alternatives guide compares it with other container platforms.

Render: a push-to-deploy PaaS

Render deploys web services, private services, background workers and cron jobs from a Git repository or a container image, with managed Postgres and Key Value instances next to them. Compared with a Lightsail instance, there is no server to patch and no nginx or process manager to configure. A push to the linked branch builds and deploys the service.

A whole app fits in a render.yaml Blueprint:

services:
  - type: web
    name: orders-api
    runtime: node
    buildCommand: npm ci && npm run build
    startCommand: node dist/server.js
    envVars:
      - key: DATABASE_URL
        fromDatabase:
          name: orders-db
          property: connectionString
  - type: cron
    name: expire-pending
    runtime: node
    schedule: "0 * * * *"
    buildCommand: npm ci
    startCommand: node dist/expire.js
databases:
  - name: orders-db

The crontab and the worker that ran on the Lightsail box become separate Render services, which makes them easier to see and restart. Scaling out means raising the instance count of a service. Render services have an ephemeral filesystem by default, and per the persistent disk docs a disk can be attached to a single instance only, and a service with a disk cannot scale out or deploy with zero downtime. Apps that write uploads to local disk on Lightsail usually move them to object storage outside Render.

The trade is that workloads run in Render's infrastructure, not an AWS account, so reaching RDS, SQS or other AWS services means going over the public internet or setting up private connectivity.

Pick it when the goal is to stop managing a server and the app does not depend on AWS services. The Render alternatives guide covers it in more depth.

Fly.io: Machines and volumes in regions you pick

Fly.io runs containers as Machines, fast-starting VMs, in the regions you choose. A volume attaches to one Machine in one region, so a service can keep files on disk across deploys, which is closer to a Lightsail instance with a disk than most container platforms get. Machines can stop when idle and start again on the next request.

The app is described in fly.toml:

app = "orders-api"
primary_region = "fra"

[http_service]
  internal_port = 8080
  force_https = true
  auto_stop_machines = "stop"
  auto_start_machines = true
  min_machines_running = 1

[mounts]
  source = "uploads"
  destination = "/data"

fly deploy builds and ships it, and fly scale count 3 --region fra,ams adds Machines in more regions. With auto_stop_machines and auto_start_machines set, the Fly proxy stops and starts those Machines based on traffic.

For data, Fly Managed Postgres runs a highly available cluster in your organization's private network with backups, failover, connection pooling, pgvector and PostGIS. As of November 2026 the docs list a 1 TB storage limit, no in-place major version upgrades and no metric alerts, and imports go through pg_dump and pg_restore. Volumes are tied to a single Machine, so a volume per Machine needs replication you handle yourself.

You give up AWS: the workloads run on Fly.io hardware and talk to AWS services over the internet.

Pick it when you need a disk, multiple regions close to users or fast-starting VMs, and are comfortable with a CLI-driven workflow. The Fly.io alternatives guide covers it in more depth.

DigitalOcean Droplets: the VPS most people compare Lightsail to

DigitalOcean

DigitalOcean Droplets are Linux VMs with CPU, memory, SSD storage and a transfer allowance in one monthly price, the same bundled model Lightsail copied. Nearly every VPS comparison that ranks for Lightsail alternatives puts DigitalOcean next to it, and the per-size prices for shared CPU Droplets sit close to Lightsail's.

Where DigitalOcean goes further is the set of products around the Droplet. Per the docs as of November 2026, shared and dedicated CPU sizes run up to 48 vCPUs, Managed Databases cover PostgreSQL, MySQL, Valkey, MongoDB, Kafka and OpenSearch with standby nodes, read-only nodes and point-in-time recovery, Spaces provides S3-compatible object storage, and Volumes add block storage you can grow without powering down. Droplet autoscale pools scale a group of Droplets on resource use, and load balancers, cloud firewalls and VPCs come from the same console.

Creating a server from the CLI, with the image and size slugs taken from doctl compute image list-distribution and doctl compute size list:

doctl compute droplet create orders-api \
  --image "$IMAGE_SLUG" \
  --size "$SIZE_SLUG" \
  --region fra1 \
  --ssh-keys "$SSH_KEY_ID" \
  --vpc-uuid "$VPC_ID"

Moving from Lightsail is mostly a server rebuild: provision the Droplet, install the stack with your existing scripts, restore the database into a managed cluster with pg_dump and pg_restore or the online migration tool, and switch DNS. You still patch the OS and run the deploy process. You also leave AWS, so the move only makes sense if the backend does not depend on AWS services.

Pick it when you want the Lightsail model with a wider set of managed databases and storage, and AWS is not a requirement.

Hetzner Cloud: low-cost servers in Europe and the US

Hetzner Cloud sells shared and dedicated vCPU servers with a large included traffic allowance, in data centers in Germany, Finland, the US (Ashburn and Hillsboro) and Singapore. For the same memory and CPU it is usually the cheapest option in VPS comparisons, and egress costs far less than on AWS, which matters when a Lightsail bundle keeps running past its transfer allowance.

The building blocks map closely to Lightsail: servers, Volumes for block storage, private Networks, stateful firewalls, load balancers, snapshots and an S3-compatible Object Storage service. Everything is available through a REST API, the hcloud CLI and a Terraform provider. Server types, images and locations come from hcloud server-type list, hcloud image list and hcloud location list:

hcloud server create \
  --name orders-api \
  --type "$SERVER_TYPE" \
  --image "$IMAGE" \
  --location "$LOCATION" \
  --ssh-key deploy \
  --network app-net

The gap is managed services. Hetzner Cloud has no managed database, no managed Kubernetes, no queues and no autoscaling, so Postgres runs on a server you set up, back up and upgrade yourself, or in a managed Postgres service from another vendor. Scaling means adding servers behind the load balancer with your own tooling. Server types and their availability also change more often than on the big clouds, so check what can be ordered in your location before planning around one.

Pick it when cost and bandwidth matter most, the team is comfortable running Postgres and servers with tools like Ansible, Terraform or Kamal, and the data can live in Europe or one of the US or Singapore locations.

Vultr: a VPS with more regions and managed databases

Vultr is the other VPS provider that shows up in almost every Lightsail comparison. Cloud Compute instances are bundled like Lightsail's, with CPU, memory, storage and transfer in one price, and Vultr runs them in more locations than Lightsail offers, across North America, Europe, Asia, Australia and South America.

The managed services cover what a small backend needs. Vultr Managed Databases support PostgreSQL, MySQL, Valkey and Kafka with automated backups and failover replica nodes, and Vultr also offers block storage, S3-compatible object storage, load balancers, VPC networks and Vultr Kubernetes Engine. Per the PostgreSQL provisioning guide, the region and plan IDs come from vultr-cli regions list and vultr-cli database plan list:

vultr-cli database create \
  --database-engine pg \
  --database-engine-version "$PG_VERSION" \
  --plan "$DB_PLAN" \
  --region "$REGION_ID" \
  --label orders-db

Moving from Lightsail looks the same as moving to DigitalOcean: rebuild the server, move the database with pg_dump and pg_restore, and switch DNS. Scaling is still manual or Kubernetes-based, OS patching is still yours, and AWS services are no longer in the same network.

Pick it when you want a bundled VPS in a region Lightsail does not cover, or a managed database next to it, without moving to a PaaS.

How to choose

• Encore if you want to stay on AWS and use RDS, SQS and Fargate, with everything defined in the code and tested locally.
• ECS Express Mode for one or two HTTP containers on AWS when the database already exists.
• EC2 if you want to keep managing servers with more instance and network options inside AWS.
• Google Cloud Run if you are on GCP and want scale to zero.
• Render for a hosted PaaS with no servers to manage and no dependency on AWS.
• Fly.io for volumes, fast-starting VMs and specific regions outside the big clouds.
• DigitalOcean Droplets for the same VPS model with a wider set of managed databases.
• Hetzner Cloud when cost and bandwidth matter more than managed services.
• Vultr for a bundled VPS and managed databases in regions Lightsail does not cover.

Related guides

• Heroku alternatives
• Render alternatives
• Fly.io alternatives
• Cloud Run alternatives