Running a vibe-code platform (Coder) on your own infrastructure
Vibe-coding is very trendy, and not just with tech people. Regular people are using AI to create and run programs, without any knowledge on how to read or write code. There’s no fighting it: the growing number of AI tools make it inevitable. So instead, it’s easier to give people inside your company a way to do that that meets good security guidelines. Over the last couple of weeks, I’ve been setting up Coder.com to run on our infra to meet our guidelines. It’s impressive the creativity that journalist can have when given the right tools, so we just want to make sure they do it in the right way.
What is Coder.com?
Coder.com is a hosted environment for managing hosted dev environments with editors, terminal access, and AI agent tooling.
Here’s a screenshot of one of the test apps I “vibe-coded” through it:
Why Coder?
For me, it comes down to main selling points: it can be hosted in your own infra, and it’s open source. The combination of cloud-hosted code editors (code-server, Claude Code, Windsurf, Cursor, etc) with optional local editors (VSCode, Vim, Jetbrains, etc) makes it handy for both developers and non-developers.
I’m pretty impressed with the platform so far. It’s not perfect, but nothing is. The rough edges seem to be both docs, and user management (currently part of the Premium features). The docs are getting better every day though - and they’ve launched a bounty program for their open source issues, which is great.
Knowledge needed to manage your Coder.com
Terraform (used for creation of workspaces + managing Coder.com itself)
Docker (used for dev environments)
How to use your hosting platform (AWS, GCP, Azure, etc)
How to use AI APIs
OpenConnect (auth management)
It’s also beneficial to if you know how to ssh in and do some old school debugging.
Starting on AWS
We use AWS, so I’ll focus on that, but the same things apply to any cloud provider. Coder provides an AMI on the AWS marketplace. The recommended EC2 instance size is t2.xlarge, but I managed to test successfully with t3.large without any issues. Make sure to assign a lot of disk space though: 10gb per user seems to be about the right size to me.
Security groups
On AWS, Coder’s docs recommend to use the default Security Group. You will probably want to lock this down. I chose to limit both http(s) and ssh to specific IPs. Since Coder uses DERP and STUN, you’ll need to allow https and UDP to specific STUN servers. Coder uses Google’s STUN servers by default, so you can limit to those IPs.
Naming limitations
Coder uses a combination of app name, agent name, workspace name and username to create the hostname for each workspace. Since there’s a DNS limit on subdomains to 63 characters, make sure your username + workspace name are short. I’d suggest using ID numbers for users, since it’s separate from their email or display name. That way workspaces can still have meaningful names.
Templates
The easiest templates to work with are those based on the Docker template. The aws-linux template needs additional permissions, including IAM roles that allow for ec2 instance management/creation. For that reason, using the Docker template is easier. I suggest managing templates on the ec2 instance rather than by the web UI, so that way it’s easier to use your normal workflows/deployment systems (Terraform, Docker, git, etc).
Claude Code with Bedrock
If you’re planning to run everything under your enterprise agreements, you might want to use Bedrock. The tasks-docker template has everything you need to setup a Claude Code instance running with a RealWorld Django app. However, if you want to use Bedrock or Vertex to run Claude, you might run into difficulties as the template expects an API key. Follow the Claude Code settings guide to figure out which env variables you need, and remove the Claude API key env var.
In my case, I needed:
CLAUDE_CODE_USE_BEDROCK
AWS_ACCESS_KEY_ID
AWS_SECRET_ACCESS_KEY
AWS_REGION
ANTHROPIC_SMALL_FAST_MODEL_AWS_REGION
ANTHROPIC_MODEL
ANTHROPIC_SMALL_FAST_MODEL
Make sure that you’re able to use Bedrock with the cross-region inference profiles within your legal area (e.g EU), as they have the best performance and the lowest cost. Other models don’t have prompt caching, so end up costing considerably more when used with Claude Code. You can use Bedrock’s guardrails to enforce security best practices too.
Once you’ve tested the demo, I suggest making your own template that starts from a very basic repo. Make sure to follow Claude Code’s best practices.
Final thoughts
It was pretty easy to set up. I got everything working as a PoC within a day. Now we’ll evaluate how our non-technical users find it, and after that see if we can scale it up, or try something else. I’ll probably share a blog post after that, too.