--- title: "How To Set Up Enterprise Development Environments with OpenAI Codex and Coder - Blog - Coder" description: "Run OpenAI Codex in self-hosted cloud development environments built for regulated enterprises. See how Coder secures AI coding agents at scale." image: "https://www.datocms-assets.com/19109/1783027872-blog_enterprise-development-environments-with-openai-codex-and-coder.png?fit=clip&fm=webp&w=800" canonical: "https://coder.com/blog/how-to-set-up-enterprise-development-environments-with-openai-codex-and-coder" --- Jul 2 20266 min read # How To Set Up Enterprise Development Environments with OpenAI Codex and Coder [Ben Potter](https://coder.com/blog/author/bpmct) Share this article [OpenAI Codex](https://developers.openai.com/codex) has evolved into a suite of agentic software development and business tools, but it has one problem: users are confined to either running workloads directly on their laptops or on OpenAI’s cloud environments. For regulated enterprises (or those with complex development environments), this effectively becomes a non-starter for widespread adoption. While some power-users can be trusted to run these workloads on laptops, the security risks (prompt injection, code exfiltration, data loss) of running locally are too high. On the other hand, OpenAI’s cloud environments are limited to running a single container per repository and lack connectivity to internal enterprise networks. The Codex agent itself is extremely capable and powerful, but there is not a proper environment to run them on with all of the proper context, security, and tooling. # Enter Coder Coder runs governed developer environments on remote infrastructure, off laptops, centralized and hardened by your platform team. Unlike OpenAI's cloud environments, Coder workspaces run entirely on your infrastructure and aren't limited to a single container per repository. Defined in Terraform, Coder workspaces can run containers, full VMs, or anything else your stack requires, on your infrastructure, inside your network, with access to your internal services, your secrets management, your CI systems, and whatever else your developers actually need to do their jobs. Workspaces come with your repositories checked out, dependencies installed, and the context Codex needs to do useful work from the moment it starts. Developers connect via browser or IDE. Codex is already there, authenticated, and configured the way your platform team decided. No local installs, no manual configuration, no API keys in dotfiles. For Codex, the workspace is the sandbox. Firewall rules, network configuration, identity, and auditing are all handled centrally. You can run full-auto mode without the risks of doing it locally, because the workspace is isolated infrastructure your platform team controls. Not a laptop with a home directory full of credentials. ## Reference architecture Coder can be deployed in a number of different ways, but the most common pattern we see from customers is AWS with EKS and Coder running on their VPC. For Codex specifically, the timing is good: Codex is now available directly on Amazon Bedrock, meaning customers running Coder on AWS can hit Codex through the same Bedrock APIs and controls they already use. No OpenAI API proxy, no separate key management story, and no new vendor relationship to manage. Codex workspaces sit behind the same network controls as everything else in that environment: egress is filtered, ingress is controlled, and the API key the agent uses is injected by the template, not typed in by the developer. ![](https://www.datocms-assets.com/19109/1783028637-open-ai-codex-coder.png) For organizations not on AWS, Coder runs on Azure, GCP, VMware, OpenShift, and on-prem. Around 40% of our customers run something other than AWS with EKS. The architecture is the same regardless: Coder's control plane manages provisioning, the workspace is where Codex runs, and the client machine stays clean. See our [guides for installing Coder on Kubernetes](https://coder.com/docs/install/kubernetes). ## Coder templates: the golden path in practice Templates are written by platform administrators and define the underlying infrastructure, dependencies, and tools for developer environments. Users pick a template from a curated list to get into a workspace. For most organizations, a single "golden template" covers the main population of users: a developer making a quick change, a product manager prototyping something, a QA engineer writing tests. That template has the languages, utilities, and tooling the team needs pre-installed and pre-configured. Codex included. Organizations with different needs can run multiple templates. A stricter template for contractors might scope Codex to a single repository. A broader one for senior engineers might have wider network access and full-auto enabled by default. Same platform, same governance, different postures. These decisions live in the template, managed by the platform team, not scattered across individual developer machines in dotfiles and shell configs nobody has audited. Because Coder is language and tooling agnostic, the same platform that runs your Codex environments also runs environments for teams that don't use Codex at all. Python, Java, Go, whatever the stack. The golden path isn't opinionated about what you build or what tools you use. It's opinionated about how environments are provisioned, secured, and managed. See our [guides for template management](https://coder.com/docs/admin/templates). ## AI governance Coder handles sandboxing and network controls. But that only stops agents from doing dangerous things in the moment. It doesn't tell you what the agent did, who ran it, which model it talked to, which MCP servers it called, what files it wrote to, or whether the configuration it ran under matched what your security team actually approved. Different teams running different versions, different API keys pointed at different endpoints, none of it logged anywhere. When something goes wrong, or when legal asks what the agent did last Tuesday, there's no answer. Coder's AI Governance Add-On handles this at the platform level. Every Codex session is fully audited and visible in the Sessions UI. Those logs can be ingested into your SIEM for storage and analysis. The configuration governing what the agent can do, which model endpoint it hits, how environment variables are handled, lives in the template. Not in a config file on someone's laptop that may or may not match what everyone else is running. Learn about [AI Governance with Coder](https://coder.com/docs/ai-coder/ai-governance). ## Looking forward Codex started as a terminal agent. It has since expanded well beyond software developers, with knowledge workers now making up roughly one in five users and growing at more than triple the rate of the core developer group. Today, [OpenAI announced the acquisition of Ona](https://openai.com/index/openai-to-acquire-ona/), bringing its secure cloud execution and orchestration technology into the Codex ecosystem to handle longer-running work across hours or days. Codex is becoming a platform. We'd like to see OpenAI take the same path [Cursor did with self-hosted cloud agents](https://cursor.com/blog/self-hosted-cloud-agents): let enterprises run Codex's agentic workflows on their own infrastructure. Regulated organizations can't send code, secrets, or build artifacts to a third-party cloud. A single container per repository doesn't reflect how real development environments work. Self-hosting support would let the full Codex experience, the IDE extensions, the background agents run on Coder or any trusted enterprise infrastructure. Until then, the Codex CLI works great in Coder today. --- **Get started** You can learn how to install [Coder Community Edition](https://coder.com/docs/install) (or start a [premium trial](https://coder.com/trial)) and have Codex running in a governed workspace in minutes. For a deeper look at how Coder fits your infrastructure, reach out to our technical sales team at [\[email protected\]](https://coder.com/cdn-cgi/l/email-protection#cdbeaca1a8be8daea2a9a8bfe3aea2a0). [![Ben Potter](https://coder.com/_next/image?url=https%3A%2F%2Fwww.datocms-assets.com%2F19109%2F1744133925-ben.jpeg%3Ffit%3Dcrop%26fm%3Djpg%26h%3D100%26w%3D100&w=2048&q=75)](https://coder.com/blog/author/bpmct) [Ben Potter](https://coder.com/blog/author/bpmct) VP of Product [HN](https://news.ycombinator.com/user?id=bpmct) Hey! I write a lot of Coder's engineering blog posts and work on projects that make it easier to develop with code-server and Coder ☁️ [Learn more about Ben Potter](https://coder.com/blog/author/bpmct) ### Subscribe to our newsletter Want to stay up to date on all things Coder? Subscribe to our monthly newsletter for the latest articles, workshops, events, and announcements.