
How do I get started with Coder Community on our own AWS account (high-level steps)?
Coder Community is designed to run on your infrastructure, so getting it live in your own AWS account is mostly about standing up the control plane cleanly, wiring identity, and defining your first Terraform-based workspace template. You’re not buying a SaaS; you’re operating a remote development platform the same way you’d run any other production service.
Quick Answer: To get started with Coder Community on your own AWS account, you’ll (1) set up an AWS environment and DNS/TLS, (2) deploy the Coder control plane (coderd) on EC2 or EKS, (3) configure OIDC SSO and basic RBAC, and (4) add a Terraform-based template so developers can self-serve workspaces on AWS in seconds.
Frequently Asked Questions
What are the high-level steps to run Coder Community in our own AWS account?
Short Answer: You’ll provision core AWS infrastructure, deploy the Coder control plane, hook up identity (OIDC SSO) and storage, then add Terraform templates that define developer workspaces on your AWS resources.
Expanded Explanation:
The core pattern is simple: Coder is a self-hosted control plane (coderd) plus workspaces defined as Terraform. In AWS, that usually means a VPC, subnets, security groups, and either an EKS cluster or EC2 instances to host Coder and workspaces. Once coderd is up, you integrate it with your identity provider via OIDC, configure basic RBAC and dev URL access levels, then register one or more Terraform templates that describe the compute, storage, and network policies you want for developer workspaces. From there, developers and AI coding agents can self-provision workspaces on demand—without you handing out direct console access to AWS.
Key Takeaways:
- You self-host Coder Community entirely in your AWS account; nothing leaves your infrastructure unless you configure it to.
- The main phases are: AWS prerequisites, coderd deployment, identity integration, and Terraform templates for workspaces.
How do I deploy Coder Community on AWS step by step?
Short Answer: At a high level, you prepare an AWS environment (networking, DNS, TLS), deploy coderd on EC2 or EKS, expose it via HTTPS, then walk through the web UI to finalize setup and add your first workspace template.
Expanded Explanation:
You can treat Coder like any other internal control plane. In smaller setups, a single EC2 instance with attached storage and a managed database is enough. In larger or regulated environments, you’ll prefer EKS with a Helm-based deployment, locked-down security groups, and strict IAM roles. Either way, you’ll want an internal or external DNS name (e.g., coder.yourdomain.com), a TLS certificate, and an authentication path via your IdP. Once coderd is reachable over HTTPS, the UI guides you through initial admin setup. Then you add a Terraform template that provisions AWS-based workspaces—usually EC2 instances or Kubernetes pods—with the required IDEs, language runtimes, and storage.
Steps:
-
Prepare AWS networking and DNS
- Create or choose a VPC, private/public subnets, and security groups for the Coder control plane and workspaces.
- Decide whether Coder will be internet-accessible or only available via VPN/private connectivity.
- Reserve a DNS name (e.g., Route 53) and plan for a TLS certificate (ACM or your PKI).
-
Deploy the Coder control plane (
coderd)- Option A (simpler): Launch an EC2 instance (Linux) with sufficient CPU/RAM and persistent storage; install Docker or a supported runtime and run the coderd container.
- Option B (scalable): Deploy Coder on EKS using Helm, assigning appropriate IAM roles, node groups, and storage classes.
- Configure a load balancer (ALB/NLB) with TLS termination and point your DNS name to it.
-
Configure Coder and add your first template
- Access the Coder web UI over HTTPS and create the initial admin user.
- Wire OIDC SSO (e.g., Okta, Azure AD, Google Workspace) and basic RBAC roles.
- Add a Terraform-based workspace template that provisions AWS compute (EC2 or EKS pods), storage, and network access for developers.
Should we run Coder on EC2 or on EKS in AWS?
Short Answer: For small teams or pilots, EC2 is simpler; for larger teams, multi-tenant clusters, or stricter governance, EKS gives you more control and scaling headroom.
Expanded Explanation:
Both EC2 and EKS are valid; the trade-off is operational complexity versus control. A single EC2 host (or small ASG) is quick to stand up and adequate if you’re testing Coder Community or supporting a smaller group of developers. You’ll manage coderd and workspaces as processes or containers on those instances.
EKS fits better when you already operate Kubernetes or need multi-tenant isolation, higher concurrency, and fine-grained policies. Coder itself runs as pods, and workspaces can also run as pods with pod-level network policies and quota controls. That makes it easier to standardize node types (including GPU), enforce limits, and plug audit logs into your existing observability stack.
Comparison Snapshot:
- Option A: EC2-based deployment
- Faster initial setup, fewer moving parts.
- Good for pilots, small teams, or non-mission-critical use.
- Option B: EKS (Kubernetes) deployment
- Stronger multi-tenant isolation and scaling.
- Better fit for platform teams that already run K8s and want standardized policies.
- Best for:
- EC2 if you want to validate Coder quickly with minimal dependencies.
- EKS if you’re aiming for long-term, multi-team, or regulated deployments.
What do we need in place before developers can self-serve workspaces?
Short Answer: You need a running Coder control plane, an identity integration (OIDC), a storage strategy, and at least one Terraform template that defines AWS-hosted workspaces.
Expanded Explanation:
Developers shouldn’t touch AWS console knobs to get an environment. Instead, they hit Coder, authenticate via your IdP, and choose a template. That template codifies what you’re willing to provide: instance size, storage, base image, IDE options, and network access to internal systems. To make this safe and repeatable, you’ll want Coder integrated with your SSO provider, a persistence plan (e.g., EBS volumes, EFS, or Kubernetes PVCs), and basic RBAC so only the right people see the right templates.
What You Need:
- Core platform setup
- A running coderd instance or cluster reachable via HTTPS and fronted by a stable DNS name.
- Persistent storage for workspace home directories (e.g., EBS/EFS or K8s volumes).
- Governed workspace definitions
- One or more Terraform-based templates that describe AWS compute, storage, network policies, and IDEs.
- OIDC SSO and RBAC rules so developers and AI coding agents get appropriate access and can provision workspaces “in seconds—straight from your templates.”
How should we think about strategy when starting Coder Community on AWS?
Short Answer: Treat Coder as your remote development control plane: define a small set of “golden path” templates, centralize code and data in AWS, and build in auditability and cost controls from day one.
Expanded Explanation:
If you start with “just get something running,” you’ll recreate the same sprawl you have on laptops, just in the cloud. A better approach is to decide which environments you actually support (e.g., “backend on EC2,” “data science on EKS + GPUs”), model them as Terraform templates, and make those the default paths. Keep secrets out of templates; instead, use IAM roles and environment configuration that your security team can review.
On AWS, you also have a chance to retire or avoid VDI-style developer desktops. Coder workspaces running on EC2 or EKS can replace heavy virtual desktops with lean, IDE-first environments accessed via VS Code Remote, JetBrains Gateway, or browser IDEs—while code stays in AWS. As you mature, you can route Coder audit logs (including workspace events and, with the Premium AI Governance add-on, AI agent prompts and tool calls) into your existing SIEM.
Why It Matters:
- Security and governance: Source code and sensitive data stay in your AWS account, with controlled network paths and identity-based access, instead of living on unmanaged laptops or a third-party SaaS.
- Speed with control: Developers onboard in minutes using standardized templates, while platform and security teams own the boundaries—compute sizes, network reach, idle-stop policies, and audit trails.
Quick Recap
Running Coder Community on your own AWS account means standing up a self-hosted control plane (coderd) in your VPC, integrating it with your identity provider, and defining Terraform-based workspace templates that allocate AWS compute and storage under your rules. Start by choosing EC2 or EKS, wiring DNS/TLS and OIDC SSO, then publishing a small set of governed templates so developers and AI coding agents can self-serve consistent workspaces in seconds—without expanding your laptop or VDI attack surface.