How AutoDeploy Works

Home base — everything starts here.

The first screen you see. It lists every repository you've connected, shows quick stats (runs, deploy targets, success rate), and has one-click cards for every config generator.

When to use it: Use it to see the state of everything at a glance, and as the fastest way into "generate a config for this repo" or "start a fresh generator."

Lets AutoDeploy actually see your code.

You install the AutoDeploy GitHub App on your account or organization and pick which repositories it can access — like handing over a specific set of keys instead of your whole GitHub password.

When to use it: Every other repo-aware feature (generators tailored to your actual code, Pipelines, Deployments) needs this connected first. Nothing reads your code without it.

Rents a real cloud server and starts your app on it for you.

A Pro/Team plugin — install it from the Plugins page first. Once installed, you give AutoDeploy narrow, revocable permission on your AWS account once (an IAM role — think of it as a guest badge, not a house key), then tell it which Docker image to run. It boots a real AWS server and starts your app on it automatically.

When to use it: Use it when you don't already have a server to deploy to and don't want to click through the AWS Console yourself. It's the closest thing to "just make my app live."

Your own servers, kept in view.

If you already have your own server (a VPS, a company machine, anything reachable over SSH), you register it here as a "deploy target" for a repository. This page shows the live, right-now status of each one — not just "last time it ran."

When to use it: Use this instead of Vision when you're deploying to infrastructure you already own rather than renting a fresh AWS server.

The running log of everything AutoDeploy has done.

Every generation run and every deployment, across every repository, newest first, in one feed.

When to use it: Use it as your "what just happened" screen — the first place to look after something runs.

Every file AutoDeploy has ever generated for you, and how it changed.

A browsable archive of generated config files (Dockerfiles, CI/CD pipelines, Kubernetes manifests, and more) plus the history of how each one changed over time.

When to use it: Use it to pull up something you generated last week without regenerating it, or to see exactly what changed between two versions.

A second pair of eyes on a config file before you trust it.

Paste in any Jenkinsfile, GitHub Actions workflow, Dockerfile, Kubernetes manifest, or Terraform file and it checks the syntax and flags likely issues.

When to use it: Use it on anything you hand-edited after generating it, or on a config file from somewhere else entirely — it doesn't have to be one AutoDeploy made.

Packages your app so it can run anywhere Docker runs.

A Dockerfile is a recipe: it lists the exact steps to build a self-contained, runnable copy of your app — called a Docker image once built (that's the same "Docker image" Vision asks for). This generator writes that recipe for you based on your base language image, install/build/start commands, and a few options like multi-stage builds and health checks.

When to use it: Start here if you don't have a Dockerfile yet — Vision, and most deploy paths, need one (or an image already built from one).

Automatically builds and deploys your app every time you push.

Generates a GitHub Actions workflow file — the config GitHub itself reads to run steps (build, test, deploy) automatically on every push.

When to use it: Use it so you stop manually re-deploying after every change.

The same automatic build-and-deploy idea, for teams running their own Jenkins server.

Generates a Jenkinsfile — Jenkins' equivalent of a GitHub Actions workflow.

When to use it: Use it if your team already runs Jenkins instead of (or alongside) GitHub Actions.

Scripts a repeatable setup for one or many servers.

Generates an Ansible playbook — a scripted list of setup steps you can re-run on any server to get it into the same known state, instead of configuring each one by hand.

When to use it: Use it when you're managing more than a couple of servers and want changes applied consistently everywhere.

For running your app across a cluster of servers instead of just one.

Generates the Kubernetes manifests (Deployment, Service, and friends) that tell a Kubernetes cluster how to run and keep your app alive — restarting it if it crashes, spreading it across machines.

When to use it: Use it once a single server isn't enough — Kubernetes is the standard way to run an app reliably at larger scale.

Describes your cloud infrastructure as a file instead of clicking through a console.

Generates Terraform configuration ("Infrastructure as Code") that describes AWS resources — so your infrastructure can be created, changed, and torn down predictably by running a command instead of clicking through the AWS Console by hand.

When to use it: Use it once you're tired of manually re-creating the same AWS setup, or want infrastructure changes reviewable like code changes.

One-off automation scripts — backups, health checks, setup tasks.

Three generators (Bash, Shell, Python) for smaller standalone scripts that don't need a whole pipeline or playbook.

When to use it: Use these for a quick, focused task — a backup script, a cleanup job, a health-check probe.

Charts built from your own history.

Stats and trends computed from your recent generation runs and deployments — success rate, volume over time, and similar.

When to use it: Use it to spot a pattern (e.g. a rising failure rate) that's easy to miss looking at Pipelines one run at a time.

A tamper-evident record of who changed what.

Every membership change, credential change, and infrastructure change in your organization, logged with who did it and when.

When to use it: Use it for security review, or to answer "who changed this and when" after the fact.

Structured learning paths, with your progress tracked.

Pick a path (e.g. a DevOps fundamentals track), work through its steps, and mark each one in-progress or completed as you go.

When to use it: Use it if you're learning DevOps/cloud concepts alongside using the product, not just using it.

A searchable library of "here's exactly how to fix that error."

Real, specific troubleshooting guides for common DevOps errors (Docker exit code 137, Kubernetes CrashLoopBackOff, Terraform state locks, and more) — each with symptoms, root cause, and copy-pasteable fix steps.

When to use it: Use it when something is broken and you recognize the error message — search it here first.

Real, runnable Terraform examples to learn from.

A library of complete example Terraform configurations for common setups.

When to use it: Use it alongside the Terraform IaC generator when you want to see a finished, working example rather than start from a blank form.

Articles from AutoDeploy and its users.

The public blog — anyone can read it, no account required.

When to use it: Use it to read what other people are writing about DevOps and this product.

Write and manage your own posts.

Your own blog-post editor — draft, publish, or unpublish posts that show up on the public Blog once published.

When to use it: Use it to write up something you learned or built.

Chat with other AutoDeploy users.

Real-time 1:1 or group chat with people you've connected with on the platform.

When to use it: Use it to ask a question or work through a problem with someone else directly, without leaving the product.

Who's allowed in, and what they can do.

Invite people to your organization, assign them a role (Owner, Admin, or Member), and remove people who leave.

When to use it: Use it any time your organization's membership changes.

Locks down your own account.

Password changes and two-factor authentication (2FA) — a second, time-based code from an authenticator app required at login, on top of your password.

When to use it: Turn on 2FA here — it's the single biggest thing you can do to stop someone else from logging in as you, even if your password ever leaks.

Who you are, for your own reference.

Your basic identity — username, work experience, areas of expertise.

When to use it: Mostly informational; fill it in if your organization is bigger and it helps teammates know who does what.

Set it once, every new repo inherits it.

Organization-wide defaults — SSH connection details, Docker Hub credentials, domain — so you don't retype the same values for every repository's deploy target.

When to use it: Use it once you have more than one repository deploying to similar infrastructure. A repository's own deploy target always overrides these when both are set.

Let your own scripts and other tools talk to AutoDeploy.

API keys for calling AutoDeploy programmatically, and webhooks for having AutoDeploy notify another system (like Slack) when something happens (a generation completes, a deployment fails).

When to use it: Use it once you want to automate something beyond what the UI covers, or pipe events into a tool you already use.

Your plan, seats, and payment method.

Where your subscription plan, seat count, and payment details live.

When to use it: Use it to upgrade, downgrade, or update payment details.