Building a Cloud Development Environment platform: Vision, Decisions, and Lessons Learned

We were featured episode #476 on one of Brazil’s most renowned technology podcasts, Hipsters.tech.

CPS1’s co-founders Miguel Di Ciurcio Filho and Oscar Esgalha joined for an in-depth conversation on Cloud Development Environments, Developer Experience, Platform Engineering, and DevOps practices. They shared stories and insights from their past experiences, revealing how CPS1 was born and the key architectural decisions that shaped it.

Here’s the conversation in text for those who prefer reading, and you can also listen to the episode on Spotify.

Question: How would you clearly summarize the service CPS1 has created and offers to developers?

Miguel: CPS1 is a platform that you install directly in your own infrastructure — whether in public or private cloud — and it provides, in a simple and fast way, the capability to create on-demand development environments following your team’s standards.

In the traditional model, when a developer joins a new company or project, they receive a laptop and may spend days or even weeks installing tools, configuring the environment, and waiting for access approvals. I’ve seen cases where onboarding took more than 30 days before the first code contribution.

With CPS1, the experience is completely different: the developer accesses a portal through a browser, creates a workspace preconfigured with all necessary tools defined by the development or platform team, and in just a few minutes is ready to work.

When we designed this solution, we also considered different scenarios: companies with mature and well-defined DevOps cycles, as well as those still at an early stage, running with older processes. We wanted something that could integrate with established structures but also offer an efficient starting point for those still building their development workflow.

Oscar: Adding to what Miguel said, from the very beginning we conceived CPS1 as a component that easily fits into a company’s platform engineering or DevOps strategy. Once installed in your own infrastructure — whether public or private — it can be extended and customized to follow existing standards and practices.

For companies that are just starting out or don’t have a dedicated DevOps team, we created a community package called Contrib, which comes with ready-to-use configurations for popular languages like Python, JavaScript, and Go. This allows teams to start using it immediately.

For companies with more specific needs — such as a customized Java runtime or their own set of libraries — CPS1 makes it possible to adapt the environment to match those exact standards, in a simple way and with minimal effort.

This was a key point in the product’s design: making customization easy and accessible, something we didn’t find in existing market alternatives when we began developing the platform.

Question: If you meet a traditional CTO who prefers local development, how do you convince them to switch to a cloud-based development environment?

Miguel: Before answering directly, let me clarify something: in the past, having a CDE (Cloud Development Environment) was almost synonymous with coding in the browser. Today, that’s no longer a requirement — though it’s still an option.

In our product, for example, the default setup includes a browser-based IDE, but we also support using your local IDE, like VS Code, connected to the workspace via SSH.This preserves the development experience the professional is already used to: shortcuts, extensions, layout, and workflow all remain the same. We know developers value these details, and we designed the product to respect that.

Now, when it comes to pitching this to a more traditional CTO, I’d have several strong points to present:

1. Flexibility and enhanced resources: Today’s systems are increasingly large and complex, often made up of multiple microservices. In a local setup, a developer can only test part of the application because they lack access to all the necessary resources and integrations. With a CDE, these services can be available inside the workspace, enabling full end-to-end testing — something that’s not feasible even on a powerful laptop.

   
   

2. Much faster onboarding: In a local environment, setting everything up can take 15 days to a month — whether for a new hire or for someone simply switching teams. With a CDE, they can start working within minutes, eliminating weeks of downtime.

   
   

3. Better team coordination: In the traditional model, back-end and front-end often work in parallel and only integrate at the end, which creates rework. With a CDE, a developer can share their running workspace with another team member, enabling immediate feedback and continuous integration, without relying on intermediate deployments.

   
   

These are just a few examples. There are other benefits, like improvements to the code review process, reducing bottlenecks, and boosting overall development speed. It’s not just about changing the environment — it’s about elevating the entire development process to a more efficient and collaborative level.

Question: How can we encourage beginners to start practicing in a cloud environment so they enter the job market already familiar with this model?

Miguel: From a beginner’s perspective, the experience changes very little. As I mentioned earlier, it’s possible to access the workspace remotely — even via SSH — and have a shell available to do whatever you need.

Today, many IDEs, such as VS Code, support remote development, letting you point your IDE to a remote server while keeping the same local experience, only working in the cloud. So for someone learning, the process of installing, configuring, and troubleshooting remains part of the journey.

The difference becomes more noticeable in a corporate environment, especially when it comes to managing source code access. In many companies, especially those working with contractors, the code often ends up on the developer’s machine — which can be a huge problem in regulated sectors like finance.With a CDE, the code stays on the company’s infrastructure, and access is done remotely. This ensures much greater control and security without compromising the development experience.

Usually, companies try to handle this by using VDI (Virtual Desktop Infrastructure), setting up virtual desktops for developers to work on remotely. But anyone who’s done it knows: it’s slow, inconvenient, and frustrating. With a CDE like CPS1 built for development, workspaces are far more efficient, removing that bottleneck and delivering a smooth, enjoyable experience.

Oscar: Just to add: when we ran our software factory, we had some hiring programs for entry-level developers. In one edition, we decided to include the use of a CDE in the technical test so candidates could spend less time setting up environments and more time coding.

The results were excellent — we received more applications, more code to review, and attracted more candidates overall, without significantly increasing our workload. So for beginners, setting up a CDE might not be all that exciting, but receiving a ready-to-use environment helps them focus on learning to code rather than wrestling with setup issues.

Question: Do you have an estimate of the machine resources required to run CPS1?

Miguel: The required resources mainly depend on the number of people using it simultaneously and the size of the applications they are running.

You also need to factor in a small overhead to support the remote IDE, which we round to about 1 GB of memory and 1 vCPU per workspace.

In terms of capacity, it’s the classic answer: it depends. If your applications require more memory, then you’ll need more memory. The calculation is straightforward: for example, if you have 20 developers working at the same time on a certain type of project, just multiply by the average consumption per developer to estimate your needs.

As for CPS1’s own computational footprint, it runs as an operator in Kubernetes — something completely transparent to the user. If I didn’t tell you, you wouldn’t even notice. It’s extremely efficient, and Oscar can share more about how we make it run with so little memory.

Oscar: This was actually one of the key reasons we decided to build our own product from scratch. When we first started the company to provide development environments for other organizations, our initial idea was to use an existing solution and offer it as a service.

However, the options we found were either very hard to install, consumed an absurd amount of resources, or both. To have almost nothing running, some solutions required at least two or three machines in a Kubernetes cluster, each with 16 GB of RAM and over 8 vCPUs.

Our operator, developed in Rust — which we’ve presented at events like Kubernetes Community Day Brazil and Rust conferences — uses only a few megabytes of memory and can support a large number of users.

In our testing, the limiting factor has been the Kubernetes API, not our platform. To get started, you basically just need your Kubernetes cluster set up and resources on the nodes to run development environments — at least 1 GB of RAM and 1 vCPU for the IDE, plus whatever your application requires.

We even use CPS1 to develop CPS1 in our daily work, and our cloud bill stays very low.

Question: Does CPS1’s security rely on its own layers or entirely on the chosen cloud provider for hosting? How is the responsibility divided in this regard?

Miguel: When we designed the product, we opted for a self-hosted model, meaning it runs 100% within your infrastructure. We are not a SaaS, and CPS1 can even operate in air-gapped environments (completely isolated from the internet), precisely to leverage and comply with your organization’s existing security policies.

If your company enforces strict governance, auditing, or log retention rules, CPS1 follows those practices seamlessly, since it operates inside your own network and under your operational control.

In addition, CPS1 has its own internal controls: for example, to access a colleague’s shared workspace, authentication is required, and all connections use TLS by default.

Everything was implemented following state-of-the-art security practices, combining your infrastructure’s protection with the platform’s built-in mechanisms.

Question: How do you plan to foster the CPS1 community, engaging current users and encouraging new people to contribute?

Miguel: When we defined the separation between the Community and Enterprise editions, we made it a principle that the Community version would not be feature-limited — unlike what many companies do.

It offers all CPS1 features, with the only restriction being the number of concurrent users, currently set at five developers. We chose this number because small teams can already benefit from a CDE, while larger teams usually have more complex needs.

Another point is that we do not require trial licenses, registration, or any entry barriers: simply access our documentation, run a single terminal command, and you’ll have CPS1 running locally to test.

We also have the Contrib repository, where you can add languages, tools, and integrations, expanding the platform’s capabilities.

Oscar: CPS1 is installed via a public Helm Chart, available for anyone to see and understand how it’s configured — including CRDs, packages, and resources.

• Packages are components installed in the workspace, such as compilers, interpreters, or development tools.

• Resources are managed services, such as databases or message queues.

Within the Helm Chart, we maintain a package called Contrib with standard examples. Our idea is to encourage more people to propose new packages to support other languages and services, building a collaborative ecosystem.

We have also created a Discord server and use GitHub — with issues and discussions — to gather suggestions for new features, report bugs, and exchange ideas.

In addition, we actively participate in the DevOps community events — we have already attended DevOpsDays editions and have confirmed presence in several others this year, including Rio de Janeiro and Brasília.

Question: What was the biggest technical challenge you faced while developing CPS1, and how did you overcome it?

Oscar: We launched the first public version of CPS1 in July, but internally this is already the fourth or fifth complete rewrite of the project. Many times, we tested implementation hypotheses, validated them with a small group of users, and realized they didn’t work as expected — so we went back to the drawing board and started over.

One of the main obstacles was attempting to adopt Devfile, a CNCF standard for defining development environments. At first, we believed it would be a good foundation for the platform. However, after analyzing how other companies and projects used it, we found that most ignored large parts of the standard and placed everything in custom fields for their own implementation. By trying to strictly follow the standard, our product became more limited and confusing. We decided to drop it, which greatly simplified development and sped up our progress.

Another challenge was experimenting with Nix/Nix Packages for environment management. While technically interesting and gaining traction in the community, we faced practical issues — particularly in cloud environments where the volume system struggled with the huge number of files generated by Nix. Additionally, for developers testing it, the initial learning curve was too steep, which hurt adoption.

These experiences taught us the importance of keeping the product easy to install, simple to use, and compatible with any cloud. Reaching that point required multiple iterations, adjustments, and simplifications.

Wrapping Up

It was a blast sharing our journey on Hipsters.tech — from the early ideas to the hard lessons and the technical decisions that shaped CPS1.

But this story only really moves forward when more people join in.

If you want to see what CPS1 can do, don’t wait:

• Spin it up right now → Quickstart Guide — one command, no signup, no trial keys.

• Dig into the details → Full Documentation — everything from architecture to customization.

• Tell us what you think → Join the conversation on GitHub — ideas, questions, feature requests, or even “this could be better” rants are all welcome.

We built CPS1 to make developers’ lives easier, and your feedback is the fastest way for us to make it even better. So go ahead — try it out and let’s keep building together.