It happens at 2am on a Tuesday. You are the only person at your 12-person startup who knows how to deploy to production, and something is broken. Your phone is buzzing. Slack is lighting up. And you realize with perfect clarity that you have become the bottleneck you swore you would never create.

This is the moment every solo ops person dreads. The moment when all those "temporary" bash scripts, manual AWS console clicks, and tribal knowledge locked in your head collide with the reality that your company is growing faster than your ability to scale yourself.

You cannot hire a DevOps engineer. Your Series A runway does not support a $150K hire to manage infrastructure. But your developers need to deploy code, your investors want to know you have production-grade infrastructure, and you personally need to take a vacation sometime this decade.

The Problem with Console Clicking

Most startups begin their AWS journey the same way. Someone creates an account, clicks through the EC2 console, launches an instance, and SSHs in to deploy the app. It works. For a while.

Then the team grows. Suddenly you need staging and production environments. You need a database. You need environment variables for API keys. You need SSL certificates. Each of these becomes another manual step, another thing to remember, another place where clicking the wrong button at 2am can take down production.

The infrastructure knowledge accumulates in exactly the wrong places. Half of it lives in your head. Half of it lives in a Google Doc that is six months out of date. The rest lives in Slack threads that nobody can find.

When a new developer joins, they ask how to deploy. You spend half a day walking them through the process. When they inevitably mess something up, you spend another half day fixing it. This is not sustainable for solo infrastructure management at a growing company.

One File to Replace It All

The fundamental problem with AWS console clicking is that there is no single source of truth. Every click creates state somewhere, but that state is not captured in code you can review, version, or share.

Convox solves this with convox.yml. This single file defines your entire application infrastructure in a format that any developer can read and understand. No Terraform modules. No CloudFormation templates. No YAML files scattered across directories.

Here is a complete example for a typical web application with a background worker and a PostgreSQL database:

environment:
  - RAILS_ENV=production
  - SECRET_KEY_BASE
  - REDIS_URL

services:
  web:
    build: .
    port: 3000
    health: /health
    scale:
      count: 2-10
      cpu: 256
      memory: 512
      targets:
        cpu: 70
    resources:
      - database
      - cache

  worker:
    build: .
    command: bundle exec sidekiq
    scale:
      count: 1-5
      cpu: 512
      memory: 1024
    resources:
      - database
      - cache

resources:
  database:
    type: postgres
    options:
      storage: 100

  cache:
    type: redis

This file tells Convox everything it needs to know. Your web service runs on port 3000, scales between 2 and 10 instances based on CPU usage, and needs access to both the database and cache. Your worker runs Sidekiq with more CPU headroom. Both services share a PostgreSQL database with 100GB of storage and a Redis instance for caching and job queues.

The environment section at the top defines which environment variables your app needs. Variables with values like RAILS_ENV=production have defaults. Variables without values like SECRET_KEY_BASE must be set before deployment, which prevents the "it works on my machine" problem where someone forgets to configure a critical API key.

This file lives in your Git repository. Every change is tracked. Every deployment references a specific commit. When something breaks, you can see exactly what changed and when. This is infrastructure as code for small teams who do not have time to learn Terraform.

Before and After: The Deployment Workflow

Let me show you what changes when you move from console clicking to Convox.

Before Convox: A typical deployment involves SSH into the server, run git pull, run bundle install, run rails db:migrate, restart the application server, manually check the logs for errors, and hope nothing breaks. If something does break, SSH back in, check which commit was running before, manually revert, and restart again. This process takes 15-30 minutes and requires your full attention.

After Convox: Run one command.

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

That is the entire deployment. Convox builds your Docker image, pushes it to a private registry in your AWS account, creates a new release, and performs a rolling deployment that keeps your application available throughout the process. If the new containers fail health checks, the deployment automatically rolls back. See the rolling updates documentation for details on how this works.

Need to roll back manually? One command.

$ convox releases -a myapp
ID          STATUS  BUILD       CREATED        DESCRIPTION
RBCDEFGHIJ  active  BABCDEFGHI  5 minutes ago
RABCDEFGHI          BAABCDEFGH  2 hours ago

$ convox releases rollback RABCDEFGHI -a myapp
Rolling back to RABCDEFGHI... OK

Rollbacks complete in seconds because the previous container images are already built and stored. You are not rebuilding anything. You are just telling the orchestrator to run the previous version. This alone transforms how you respond to production incidents.

Letting Developers Deploy Without AWS Access

Here is the scenario that terrifies every solo ops person: giving developers access to the AWS console. You know what happens. Someone accidentally terminates the production database. Someone changes a security group and opens port 22 to the world. Someone provisions a massive EC2 instance and forgets about it, leaving you with a surprise $3,000 bill.

Convox solves this with role-based access control that decouples application deployment from infrastructure management. Your developers never need AWS console credentials. They interact only with the Convox CLI and Console, which enforces permissions at every step.

The RBAC system provides pre-built roles that map to common team structures:

DeveloperV2 gives your engineers exactly what they need: write access to applications, read access to the dashboard and job statuses, and read access to rack details. They can deploy code, view logs, and check service status. They cannot modify infrastructure, change rack parameters, or access billing.

OperatorV2 adds infrastructure management permissions for senior engineers or tech leads who need to manage rack configurations and integrations while still being restricted from billing and user management.

Administrator provides full access for founders and senior leadership who need complete control.

You can also create custom roles with fine-grained permissions. Need to give a contractor deploy access to only the staging environment? Create a role that grants write access to specific applications on specific racks. The deploy keys feature extends this to CI/CD systems, giving your automated pipelines exactly the permissions they need and nothing more.

This permission model means you can onboard a new developer in minutes instead of hours. They install the CLI, you add them to the organization with the appropriate role, and they can immediately start deploying to staging. No IAM policy reviews. No hoping they do not click the wrong thing in the AWS console.

Managing Configuration Without Spreadsheets

Environment variables are a constant source of deployment failures. Someone updates an API key in production but forgets to update staging. Someone adds a new variable to their local environment but never tells anyone else. The classic "it works on my machine" becomes "it works in staging but breaks in production."

Convox manages environment variables as part of the release system. Every change creates a new release that can be promoted, inspected, or rolled back. Check the environment variables documentation for the complete reference.

$ convox env -a myapp
RAILS_ENV=production
SECRET_KEY_BASE=abc123...
DATABASE_URL=postgres://...
REDIS_URL=redis://...

$ convox env set STRIPE_API_KEY=sk_live_xxx -a myapp
Setting STRIPE_API_KEY... OK
Release: RCDEFGHIJK

$ convox releases promote RCDEFGHIJK -a myapp
Promoting RCDEFGHIJK... OK

Notice that setting an environment variable creates a new release but does not automatically deploy it. This is intentional. You might want to batch multiple changes together, or you might want to coordinate the deployment with other work. When you are ready, promote the release.

The release system maintains a complete history of your application state. You can see which environment variables were active for any deployment, making it easy to diagnose issues like "this worked last week, what changed?"

Answering "Who Deployed What and When"

Accountability becomes critical as your team grows. When something breaks in production, you need to answer three questions quickly: What changed? When did it change? Who made the change?

Convox captures this information automatically. Every deployment, every environment variable change, every scale adjustment is logged with the user who performed it and a timestamp.

The release history shows exactly what happened:

$ convox releases -a myapp
ID          STATUS  BUILD       CREATED         DESCRIPTION
RCDEFGHIJK  active  BABCDEFGHI  10 minutes ago  env add:STRIPE_API_KEY
RBCDEFGHIJ          BABCDEFGHI  2 hours ago
RABCDEFGHI          BAABCDEFGH  1 day ago       env remove:DEBUG_MODE

Each release has a description that explains what changed. Build releases reference the commit. Environment changes list which variables were added or removed. This audit trail is invaluable for post-incident reviews and compliance requirements.

For organizations with compliance requirements, the Convox Console provides detailed audit logs that track all user actions across your organization. You can see who logged in, who deployed what, and who changed permissions, all in one place.

The Comparison: Manual Process vs Convox Workflow

Let me make this concrete with a side-by-side comparison of common tasks.

The time difference is dramatic. What used to take 30 minutes of focused attention now takes 30 seconds. More importantly, any developer on your team can do it without risk of breaking something unrelated.

The Migration Path: From Console to Convox

You do not need to migrate everything at once. Here is a practical path from console clicking to repeatable deployments.

Week 1: Install a Rack and deploy your staging environment. Follow the getting started guide to install a Convox Rack in your AWS account. Create your convox.yml file based on your existing architecture. Deploy your application to staging and verify everything works.

Week 2: Migrate your team to Convox for staging deployments. Add your developers to the Convox organization with appropriate roles. Train them on the basic CLI commands. Let them deploy to staging while you continue managing production manually.

Week 3: Move production to Convox. Once your team is comfortable with staging deployments, migrate production. The convox.yml file is the same; you are just deploying to a production Rack instead of staging.

Week 4: Enable autoscaling and optimize. Configure autoscaling based on CPU or memory usage. Review the autoscaling documentation to fine-tune your thresholds. Set up monitoring and alerting using the built-in monitoring features or integrate with your existing tools.

What You Get Back

The real benefit of AWS deployment automation through Convox is not the time savings on individual deployments. It is the mental space you reclaim.

When deployments are one command, you stop dreading them. When rollbacks are instant, production incidents become manageable instead of panic-inducing. When any developer can deploy, you stop being a bottleneck.

You can take a vacation knowing that your team can handle deployments without you. You can focus on building features instead of maintaining infrastructure. You can sleep through the night instead of being the only person who can fix production.

This is what small team deployment should look like. Not a dedicated DevOps engineer managing infrastructure full-time, but infrastructure that manages itself while your entire team focuses on building your product.

Get Started

Ready to stop being the deployment bottleneck? Convox gives your team production-grade infrastructure without the complexity of raw Kubernetes or the risk of manual AWS management.

The Getting Started Guide walks through installing a Rack in your AWS account and deploying your first application. You can have a working staging environment in under an hour.

Create a free account and deploy your first Rack today. Your infrastructure runs in your own AWS account, giving you full control while Convox handles the orchestration.

Questions about migrating your existing infrastructure? Reach out to our team for guidance on your specific setup.