You open the AWS console. You see 200+ services. You need to deploy a web application with a database. Where do you even start? EC2? ECS? EKS? Lambda? Elastic Beanstalk? Each option leads to a rabbit hole of VPCs, subnets, security groups, IAM roles, and configuration files that seem designed for people with infrastructure degrees.

So you close the tab. Again.

If you are a developer at a small startup, this scenario probably feels familiar. You have built something worth deploying to production. You know AWS is the right choice for scale and reliability. But the gap between "working locally" and "running in production on AWS" feels like it requires hiring a full DevOps team or spending three months learning Kubernetes.

It does not have to be this way. This guide will show you how to deploy to AWS without becoming an infrastructure expert, using Convox to handle the complexity while you focus on shipping features.

The Problem with "Simple" AWS Deployment

Before diving into the solution, let us acknowledge why deploying to AWS without DevOps expertise is genuinely difficult. To run a basic web application with a database, you need to provision or configure at least the following:

• VPC: Virtual Private Cloud with proper CIDR ranges
• Subnets: Public and private subnets across multiple availability zones
• Internet Gateway: For public internet access
• NAT Gateways: For private subnet outbound traffic
• Security Groups: Firewall rules for each component
• Load Balancer: To distribute traffic and terminate TLS
• EKS Cluster: If you want container orchestration
• Node Groups: EC2 instances to run your containers
• IAM Roles: Permissions for every component to talk to each other
• RDS Instance: Managed database with proper security

Each of these resources has dozens of configuration options. Get one wrong, and your application either does not work or is insecure. Try to manage this with Terraform, and you are suddenly maintaining hundreds of lines of HCL that you do not fully understand.

This is the exact problem Convox solves. Instead of learning AWS infrastructure, you describe what you want to run, and Convox handles how to run it securely on AWS.

What Happens When You Install a Convox Rack

A Convox Rack is an isolated set of computing resources installed into your own AWS account. When you run the installation command, Convox creates everything you need for production-grade infrastructure automatically.

First, you need to have AWS credentials configured and the Convox CLI installed. Then the installation is a single command:

$ convox rack install aws production region=us-east-1

This single command creates the following resources in your AWS account:

• EKS Cluster: A managed Kubernetes cluster with proper security defaults
• VPC: A dedicated network with the CIDR range 10.1.0.0/16
• Subnets: Public and private subnets across three availability zones
• NAT Gateways: For secure outbound traffic from private subnets
• Security Groups: Properly configured firewall rules
• Network Load Balancer: For routing traffic to your applications
• Auto-scaling Node Groups: EC2 instances that scale based on demand
• ECR Registry: Private container registry for your application images

The installation takes 15 to 20 minutes. When it completes, you have production-ready infrastructure that would take a dedicated DevOps engineer days to configure properly. More importantly, this infrastructure follows AWS best practices by default: nodes run in private subnets, traffic is encrypted, and security groups follow the principle of least privilege.

You can verify your Rack is running with a simple command:

$ convox rack
Name      production
Provider  aws
Router    router.0a1b2c3d4e5f.convox.cloud
Status    running
Version   3.18.0

Describing Your Application with convox.yml

With your infrastructure running, the next step is describing your application. Convox uses a single configuration file called convox.yml that lives in your project root. This file describes everything about your application: what services to run, what databases you need, environment variables, health checks, and scaling configuration.

Here is a complete example for a typical web application with a Postgres database:

environment:
  - PORT=3000
  - NODE_ENV=production
  - DATABASE_URL

resources:
  database:
    type: postgres
    options:
      version: 15
      storage: 20

services:
  web:
    build: .
    port: 3000
    health:
      path: /health
      interval: 5
      timeout: 3
    scale:
      count: 2-10
      cpu: 256
      memory: 512
      targets:
        cpu: 70
    resources:
      - database
    environment:
      - SESSION_SECRET

  worker:
    build: .
    command: node worker.js
    scale:
      count: 1
      cpu: 256
      memory: 512
    resources:
      - database

Let us break down what each section does:

The environment section at the top level defines variables available to all services. Variables with values (like PORT=3000) have defaults. Variables without values (like DATABASE_URL) must be set before deployment. Convox will automatically inject the database connection string when you link a resource, so DATABASE_URL gets populated automatically.

The resources section defines backing services. In this case, we are provisioning a Postgres database. When deployed, Convox creates a containerized Postgres instance and automatically injects the connection URL into any service that lists database in its resources. For production workloads requiring more durability, you can use rds-postgres to provision an actual AWS RDS instance instead.

The services section defines your application components. The web service exposes port 3000, has a health check endpoint, and autoscales between 2 and 10 instances based on CPU usage. The worker service runs a background job processor with a fixed scale of 1 instance.

For complete documentation on all available options, see the convox.yml reference.

The Developer Workflow

With your convox.yml in place, deploying to AWS becomes a straightforward workflow that you can execute entirely from your terminal.

Creating Your Application

First, create an application on your Rack:

$ convox apps create myapp
Creating myapp... OK

This creates an empty application container. You can verify it exists:

$ convox apps
APP    STATUS   RELEASE
myapp  running

Setting Environment Variables

Before deploying, set any required environment variables:

$ convox env set SESSION_SECRET=your-secret-key -a myapp
Setting SESSION_SECRET... OK
Release: RABCDEFGHI

Notice that setting environment variables creates a new release. Convox treats environment changes as deployable units, making it easy to roll back configuration changes just like code changes. See the environment variables documentation for more details.

Deploying Your Application

Deploy your application with a single command:

$ convox deploy -a myapp
Packaging source... OK
Uploading source... OK
Starting build... OK
Building: .
Step 1/5 : FROM node:18-alpine
...
Build: BABCDEFGHI
Release: RBCDEFGHIJ
Promoting RBCDEFGHIJ...
OK

This command packages your source code, builds Docker images, pushes them to your private ECR registry, and performs a rolling deployment. The rolling deployment ensures zero downtime by gradually replacing old containers with new ones, only proceeding when health checks pass.

Viewing Your Application

Once deployed, find your application URL:

$ convox services -a myapp
SERVICE  DOMAIN                               PORTS
web      web.myapp.0a1b2c3d4e5f.convox.cloud  443:3000

Convox automatically provisions a TLS certificate and configures HTTPS for your application. No manual certificate management required.

Viewing Logs

Stream logs from all your application processes:

$ convox logs -a myapp
2024-01-15T10:30:00Z service/web/abc123 Server started on port 3000
2024-01-15T10:30:01Z service/web/abc123 Connected to database
2024-01-15T10:30:05Z service/web/def456 Server started on port 3000
2024-01-15T10:30:06Z service/worker/ghi789 Worker process started

You can filter logs by service using the --service flag or search for specific strings with --filter. See the logging documentation for all available options.

Rolling Back

If something goes wrong, roll back to a previous release:

$ convox releases -a myapp
ID           STATUS  BUILD        CREATED        DESCRIPTION
RCDEFGHIJK   active  BCDEFGHIJK   5 minutes ago
RBCDEFGHIJ           BABCDEFGHI   1 hour ago
RABCDEFGHI           BABCDEFGHI   2 hours ago    env add:SESSION_SECRET

$ convox releases rollback RBCDEFGHIJ -a myapp
Rolling back to RBCDEFGHIJ... OK, RDEFGHIJKL
Promoting RDEFGHIJKL...
OK

Rollbacks are nearly instantaneous because Convox maintains the history and container images for all previous releases. This makes recovering from failed deployments a matter of seconds, not minutes. Learn more about rollbacks and rolling updates.

Built-in Security Defaults

One of the biggest advantages of using Convox for simple AWS deployment is that you get production security defaults without having to understand or configure them yourself.

You can customize these defaults when needed. For example, to enable vulnerability scanning on container images pushed to ECR:

$ convox rack params set ecr_scan_on_push_enable=true
Setting parameters... OK

The full list of configurable rack parameters lets you tune your infrastructure without diving into the AWS console.

What You Do Not Need to Learn

The most significant benefit of deploying to AWS without a DevOps team through Convox is all the technology you can skip learning. For day-to-day operations, you never need to touch:

kubectl: Convox abstracts away direct Kubernetes interaction. You scale services, view logs, and execute commands through the Convox CLI, not kubectl. If you ever need direct cluster access for advanced debugging, you can export a kubeconfig, but this is optional and rare.

Helm charts: No need to write or manage Helm charts. Your convox.yml declares what you want, and Convox handles the Kubernetes manifests internally.

IAM policies: Convox creates and manages the IAM roles needed for your infrastructure. You do not need to understand the intricacies of AWS permissions to deploy securely.

CloudFormation or Terraform: No infrastructure-as-code files to maintain. Convox manages the underlying infrastructure through its own system.

VPC networking: Subnets, route tables, NAT gateways, and security groups are all configured automatically based on best practices.

Container orchestration details: Rolling deployments, health checks, container scheduling, and restart policies are handled automatically based on your simple convox.yml configuration.

Scaling Your Application

As your application grows, scaling with Convox remains straightforward. You can configure autoscaling directly in your convox.yml:

services:
  web:
    scale:
      count: 2-10
      cpu: 256
      memory: 512
      targets:
        cpu: 70
        memory: 80

This configuration maintains between 2 and 10 instances, scaling up when CPU usage exceeds 70% or memory exceeds 80%. The underlying Kubernetes Horizontal Pod Autoscaler handles the actual scaling logic.

For immediate manual scaling:

$ convox scale web --count 5 -a myapp
Scaling web...
OK

See the scaling documentation for more details on autoscaling configuration and resource allocation.

When You Need Production Databases

The containerized resources that Convox provisions by default are excellent for development and staging. For production workloads requiring managed databases with automatic backups and high availability, Convox supports AWS RDS directly:

resources:
  database:
    type: rds-postgres
    options:
      class: db.t3.medium
      storage: 100
      version: 15
      encrypted: true
      durable: true
      deletionProtection: true
      backupRetentionPeriod: 7

This provisions an actual AWS RDS instance with encryption, Multi-AZ deployment for high availability, and automated backups. The DATABASE_URL environment variable is still injected automatically into linked services. See the Postgres resource documentation for all configuration options.

Adding Custom Domains

When you are ready for a custom domain instead of the auto-generated Convox URL, update your convox.yml:

services:
  web:
    domain: app.yourdomain.com

Then point your DNS to your Rack's router, which you can find with convox rack. Convox automatically provisions and renews TLS certificates for your custom domain using Let's Encrypt. For more flexibility, you can use environment variable interpolation:

services:
  web:
    domain: ${WEB_HOST}

This lets you set different domains per environment without changing your manifest. See the custom domains documentation for complete setup instructions.

The Developer-Friendly Path to AWS

Deploying to AWS without DevOps expertise is entirely achievable. The key is abstracting away the accidental complexity of AWS while preserving the essential complexity of your application. Convox provides this abstraction by giving you a simple interface for what matters to you as a developer: describing your services, setting environment variables, deploying code, and viewing logs.

Behind the scenes, you get production-grade infrastructure running in your own AWS account. You maintain full ownership and control of your infrastructure. If you ever need to dive deeper, the underlying EKS cluster is standard Kubernetes that you can access directly.

For a 5 to 15 person startup, this approach eliminates the false choice between "simple but limited" platforms and "powerful but complex" cloud infrastructure. You get the power of AWS with the simplicity your team needs to stay focused on building your product.

Get Started

Ready to deploy your application to AWS without the infrastructure headaches? The Getting Started Guide walks through installing the CLI, setting up a Rack, and deploying your first application in about 30 minutes.

Create a free Convox account to get started. You can install a Rack directly into your own AWS account and deploy your first application today.

For teams with specific compliance requirements or questions about enterprise features, reach out to our team.