Docs · Guides

Migrate from AWS

Service-by-service mapping for teams moving a workload from AWS to CloudNx. Read the table to translate concepts, then follow the runbook for a typical web-app+Postgres stack.

Service mapping

What you keep

• Your application code — most stacks need zero changes (Node, Go, Python, Java, Ruby, .NET all work identically).
• Your S3-compatible SDK calls — point at s3.cloudnx.in and you’re done.
• Your Terraform — a CloudNx provider ships in v1.1; until then, the cloudnx CLI is scriptable from Makefiles.
• Your CI: GitHub Actions / GitLab CI / Buildkite all work. Push images to registry.cloudnx.in instead of ECR.

What changes

• Region. Today we run a single EU West region. Most B2B workloads tolerate the ~135 ms RTT from Mumbai fine; if you need sub-50 ms for end-users, wait for the Indian region (Q3 2026).
• Compute SKUs. We don’t do GPU / Inferentia / Graviton — pure x86_64. m / c / r / t families with predictable pricing. No spot, no Savings Plans (yet).
• VPC. v1 is logical-only. Physical VPC isolation (per-customer Linux bridge, isolated routing) lands in v1.1.
• Billing. Single invoice in INR with GST. Per-minute billing, no Reserved Instances, no Marketplace. Postpaid available for trusted customers (similar to AWS Enterprise terms).

Runbook: web app + Postgres

A typical migration moves a 2-tier stack in ~2 hours. We use AWS account-A as source, CloudNx as target.

1. Capture the source state

# On the source EC2:
sudo pg_dumpall > /tmp/dump-$(date +%Y%m%d).sql
gzip /tmp/dump-*.sql

# Sync your application code and config to the target later via Git/S3.

2. Provision CloudNx

cloudnx instance create \
  --name app-01 \
  --type cnx.m1.medium \
  --image ubuntu-24.04 \
  --ssh-key my-key

cloudnx volume create --name pg-data --size 100
cloudnx volume attach pg-data --instance app-01

3. Restore Postgres

# On the new VM:
sudo apt-get update && sudo apt-get install -y postgresql-16
sudo systemctl stop postgresql

# Mount the volume at /var/lib/postgresql:
sudo mkfs.ext4 /dev/vdb
sudo mount /dev/vdb /var/lib/postgresql

# Restore:
sudo -u postgres psql < /tmp/dump-YYYYMMDD.sql.gz
sudo systemctl start postgresql

4. Deploy the app

Push your container image to the CloudNx registry and pull on the new instance:

docker tag myapp registry.cloudnx.in/_/myapp:latest
docker login registry.cloudnx.in -u $CNX_ACCESS_KEY -p $CNX_SECRET_KEY
docker push registry.cloudnx.in/_/myapp:latest

# On the VM:
docker pull registry.cloudnx.in/_/myapp:latest
docker run -d --restart=always -p 80:8080 registry.cloudnx.in/_/myapp:latest

5. Cut DNS

Once you’ve verified the new stack responds correctly, lower your TTL to 60s on the source DNS provider, wait an hour, then flip A records to the CloudNx Elastic IP. Roll back by flipping the records again — no data movement required.

What we don’t have yet

We’re honest about gaps:

• No Spot instances. No Reserved-Instance discounts (use postpaid + annual commit for similar savings).
• No EFS-equivalent shared filesystem. Use S3 for shared blobs or run your own NFS on a VM.
• No CloudFormation / CDK. Terraform provider is in development. The cloudnx CLI is fully scriptable today.
• No Marketplace. Bring your own SaaS contracts.
• No GPU instances. ML inference on CPU is fine for most workloads; GPU coming with our 2nd region build-out.

Ask for help

Migrations from production AWS workloads usually go through a 30-min architecture call first. Email [email protected] with subject [Migration]and a short description of your stack — we’ll respond within one business day with a proposed plan and gotchas to watch for.