For the past couple of months, the concept of MCP has been booming. MCP (Model Context Protocol) was developed and released by the end of 2024 by Anthropic. It allows AI agents and LLMs to interact with third-party APIs in order to work with real data and allows them to make actions on your behalf.

In the case of a Redis MCP, as you will see further in the blog, it means that you can search through your database using natural language.

Now, to utilize MCP and allow it to interact with other APIs, you will need an MCP server that exposes tools for your agents to use.

The big question is how to run your MCP servers without making life harder for your developers. Having everyone set up their own local server is tedious and invites all kinds of inconsistencies. Centralizing it as a shared service keeps things simple, secure, and lets your team focus on building, not babysitting servers.

Through the blog, we will cover how you can run MCP servers on Kubernetes. With such a setup, you can use them for different use cases and allow your developers to connect to them without a hassle.

Support us 🙏​

We know that Kubernetes can be difficult. That is why we created Cyclops, an open-source framework for building developer platforms on Kubernetes. Abstract the complexities of Kubernetes, and deploy and manage your applications through a customizable UI that you can fit to your needs.

We're developing Cyclops as an open-source project. If you're keen to give it a try, here's a quick start guide available on our repository. If you like what you see, consider showing your support by giving us a star ⭐

⭐ Star Cyclops on GitHub ⭐

Anatomy of an MCP server​

MCP servers support two types of transport, or “how an AI agent communicates with the server” - stdin and SSE.

Stdin servers are run as a binary, and the agent creates requests to the server through the standard input and receives the responses through the standard output. This works well locally, but in a company setup, having every developer run a server can get messy.

On the other hand, the servers with SSE (Server-Sent Events) transport communicate via HTTP. Agents subscribe to the server on the SSE endpoint to receive responses, and then initiate requests via POST requests.

With the SSE transport, the MCP server is centralized in a controlled environment and exposed as a shared service. This not only improves the developer experience by eliminating the need for individual setup but also reduces configuration inconsistencies and minimizes the risk of introducing security vulnerabilities from locally managed instances.

MCP servers architecture setup​

We created a setup on how you can deploy your favorite MCP servers to your Kubernetes cluster. After you are done deploying your MCPs, you will have a centralized place where you can easily manage them inside the cluster or deploy new ones.

With Cyclops, we created a custom template that allows you to easily deploy MCP servers through a UI - even deploying a custom MCP server from a Docker image.

In the image above is the architecture suggested earlier.

A dedicated engineering team owning MCP servers can run and manage them through the Cyclops UI. The team can configure the MCP servers to communicate with existing third-party applications like Grafana and Redis.

From there, all the other engineers can simply connect their Cursor to the exposed MCP server and allow it to make actions on their behalf.

Below are the exact setups on how to try this out yourself! Let us know what you think!

Run MCP servers on Kubernetes​

To run your MCP servers, there are a couple of prerequisites:

• a running Kubernetes cluster
  • If you don’t have a running cluster, you can create one with minikube.
• kubectl installed
• AI agent - we used Cursor in the tutorial

You can now install Cyclops into your Kubernetes cluster with the following command (comes with the UI for deploying MCP servers):

kubectl apply -f https://raw.githubusercontent.com/cyclops-ui/cyclops/v0.20.3/install/cyclops-install.yaml && kubectl apply -f https://raw.githubusercontent.com/cyclops-ui/cyclops/v0.20.3/install/demo-templates.yaml

It will create a new namespace called cyclops and deploy everything you need for your Cyclops instance to run.

Now all that is left is to expose the Cyclops server outside the cluster:

kubectl port-forward svc/cyclops-ui 3000:3000 -n cyclops

You can now access Cyclops in your browser on http://localhost:3000.

Redis MCP Example​

Now that your Cyclops is up, we can run a Redis instance inside our cluster along a Redis MCP connected to that instance.

To run a Redis instance, go to Cyclops and click “Add module”. You can now select from a bunch of templates, from which you can choose the Redis template.

You can now set authentication for your instance (will be used for connecting an MCP server to your instance):

I set my password to my-secret-password - we will need it later when connecting our Redis MCP to it. I can now hit Deploy to run my Redis instance.

You will now be redirected to the Module details page showing your Redis coming to life. Once your Redis instance is ready, you can create an MCP server and connect it to manage your instance.

To run an MCP server, go to the Add Module screen and select the mcp-server template. In the Configure section, there will be a dropdown determining what kind of MCP server you need, which in this case is redis.

To authenticate the MCP server to the Redis instance we just deployed, we need to pass it the host and the password:

• REDIS_HOST - host of your instance. Your instance should be accessible on {module name}-redis-master.{namespace}. The instance we deployed is called cache and is running in the default namespace - hence cache-redis-master.default
• REDIS_PORT - default port is 6379 which we didn’t change
• REDIS_PWD - set in the auth previously. In our case, my-secret-password. For production use cases, you can use the secret references below in the UI.

Once your MCP server is up and running you need to expose it outside of your cluster. Fort testing, you can do it by port-forwarding it. You can do that by running the following command:

kubectl port-forward -n default svc/redis-mcp 8000:8000

If you named your MCP module differently, replace redis-mcp with the name of your Module.

You can now configure Cursor to connect to your MCP server in the JSON configuration:

{
  "mcpServers": {
    "redis": {
      "url": "http://localhost:8000/sse"
    }
  }
}

You can now ask Cursor about the state of your Redis database and data inside it.

Other MCP servers​

With the template you just used, you can easily deploy a Wikipedia MCP server, a Grafana MCP server, or something custom by selecting custom in the service dropdown and defining the Docker image in the Custom Docker image override section.

Final thoughts​

We believe that AI is finding its place in the developer workflow, but there should be levels of abstractions and validations to enable it and make it as safe as possible. This is our first step in this direction.

We built this open-source; feel free to try it out and let us know what you think! Join our Discord and help shape the discussion around AI and Kubernetes 🙌

⭐ Star Cyclops on GitHub ⭐

Helping developers ship software quickly and safely is one of the most rewarding parts of building a great engineering culture. But as teams grow, systems evolve, and responsibilities shift, things can start to get… a little chaotic.

Deployments get more complicated. Onboarding gets slower. Support requests start piling up. It’s not anyone’s fault - it’s just a sign that you are ready for the next step.

More and more teams are turning to Internal Developer Platforms (IDPs) to help developers self-serve and keep their momentum.

But how do you know when it's time to invest in one?

We put together a lighthearted guide - told through memes - to help you spot the signs early. If you recognize a few of these, you're not broken, you're just “mature” enough for a better way to build and ship.

Support us 🙏​

We know that Kubernetes can be difficult. That is why we created Cyclops, an open-source framework for building developer platforms on Kubernetes. Abstract the complexities of Kubernetes, and deploy and manage your applications through a customizable UI that you can fit to your needs.

We're developing Cyclops as an open-source project. If you're keen to give it a try, here's a quick start guide available on our repository. If you like what you see, consider showing your support by giving us a star ⭐

⭐ Star Cyclops on GitHub ⭐

🚩 Sign #1: Developers constantly ping DevOps asking for “just a quick hand”​

No matter how much you automate, someone always needs "just one little thing."

Maybe it’s a config tweak. Maybe it’s a manual deployment. Maybe it’s an “emergency” that's really just a Friday afternoon feature rollout.

Every interruption might feel small, but together, they pull DevOps engineers away from bigger projects.

An IDP puts the power in developers' hands, letting them handle common workflows themselves - without hijacking your sprint.

🚩 Sign #2: Onboarding a new engineer takes a long time​

Getting new developers onboarded to your system is never easy. It’s always a struggle to get accustomed to a new codebase, but having to learn all the processes, steps and rules to running that codebase is a job in itself.

Having all of that offloaded to an IDP, where new developers can run their codebase with a couple of button clicks is a huge timesaver. Also, it is shown to reduce developer churn!

🚩 Sign #3: You find yourself praying before every deployment​

Shipping code should feel boring - in a good way.

The metrics that DORA looks for when determining the maturity of DevOps within an organization is how often new code is pushed to production and how fast it takes to get there. An IDP allows developers to ship faster, more often, and with confidence - less tickets, less gatekeeping, and less stress.

🚩 Sign #4: Your 'deployment guide' is a 47-step outdated Google Doc​

Sure, at one point the documentation was beautiful.

Then the system evolved, the workflows changed, and suddenly your "official deployment guide" is two releases behind and filled with half-truths.

An IDP turns that messy checklist into a clear, consistent workflow that actually matches reality.

🚩 Sign #5: Developers have PTSD from editing IaC​

Infrastructure as Code is powerful - but usually, it’s not exactly beginner-friendly. While DevOps engineers might be comfortable digging into it, most developers just want to deploy their service and move on.

A good internal developer platform hides that complexity behind intuitive interfaces - whether it’s a UI, CLI, or API. Developers get a clear, guided path to configure their services, while DevOps keeps the power and flexibility under the hood.

🚩 Sign #6: Your developers are better at Kubernetes than your DevOps team… accidentally​

It’s great when developers are curious and eager to learn but if they’re forced to become Kubernetes experts, it’s a sign of friction. Sure, it's a good skill to have - but it also means your system is asking too much.

With a developer platform, you can give them easy-to-use tools that abstract the complexity, speed up deployments, and let them stay focused on what they do best: building great products.

🛡️ If these hit a little too close to home...​

You’re not alone - and you’re not stuck.

Cyclops helps you build an internal developer platform in a jiffy on top of your existing tech stack. Customizable for DevOps, intuitive for developers.

Learn more about Cyclops and give your team the platform they deserve.

Or at least give your DevOps engineers their weekends back.

⭐ Star Cyclops on GitHub ⭐

There’s been a ton of hype around AI and developer workflows, but when it comes to Kubernetes, not much has really happened yet - and for good reason. You want your infrastructure to be stable, and vibe coding isn’t exactly known for stability.

Imagine your config being rewritten every time you deploy. Even a tiny change like adding an env variable could snowball into a broken system. Or worse: you wake up to a massive AWS bill because your LLM decided you really needed a few extra nodes while all you were trying to do was bump a Docker image version.

But what if you could put guardrails in place to prevent all that?

Today, we are launching our very own MCP server for Cyclops, and in this post, I’ll show you how you can enable your devs to safely deploy their code to Kubernetes by chatting with an LLM! Vibe deploying? 👉👉

Support us 🙏​

We know that Kubernetes can be difficult. That is why we created Cyclops, an open-source framework for building developer platforms on Kubernetes. Build golden paths from your existing configuration and enable safe self-service for your developers and AI agents!

We're developing Cyclops and Cyclops MCP as open-source projects. If you're keen to give it a try, here's a quick start guide available on our repository. If you like what you see, consider showing your support by giving us a star ⭐

⭐ Star Cyclops MCP on GitHub ⭐

What is an MCP server?​

By the end of last year, Anthropic launched the open-sourced Model Context Protocol (MCP) as a way for AI agents to interact with third-party services and APIs. The main goal of the MCP is to standardize how AI agents interact with your data and services.

With an MCP server, your AI agents can safely act on your behalf**.** Instead of guessing which API endpoints to call or listing possible commands for a CLI that might or might not work, they now know what they can use.

Also, with an MCP server, your agents are aware of the state of the tools you are using. Meaning that it can now know what Grafana dashboards it can use, what repos you have stored on GitHub, or what tags are available for a Docker image. Just data, no hallucinations, and made-up contexts.

For each of your models and AI agents, you can configure which MCP servers they should connect to to take action on your behalf. For each of the vendors I mentioned above (Grafana, GitHub, and Docker), there is a corresponding MCP server that translates agent requests into real actions on said providers.

Since Cyclops is all about making developers' lives easier, we implemented our own MCP server that you can install into your Kubernetes cluster and deploy your applications using natural language.

Cyclops MCP​

Check Cyclops MCP on GitHub

Cyclops itself is a tool to abstract your Kubernetes configuration behind a customizable and simple UI. Under the hood, all Cyclops applications can be defined as Kubernetes objects. To define an application, Cyclops introduces a Kubernetes CustomResourceDefinition called Module.

When a developer creates an application through Cyclops' UI, the Cyclops backend will create an instance of a Module. Cyclops MCP exposes tools for managing Modules and templates from which to create Modules.

Cyclops MCP is not cutting the DevOps out of the equation - the DevOps engineer is responsible for creating templates and making sure applications are following best practices. Through templates, DevOps engineers will define which low-level K8s resources will be created and what configuration developers and AI agents should follow when deploying an application.

You can now ask your AI agent to deploy your app using natural language. It translates your request into a configuration that meets the DevOps engineer's schema, ensuring best practices and production readiness.

Prerequisites​

Prerequisites to try out Cyclops MCP are to have a running Kubernetes cluster, kubectl installed, and Cyclops installed in your cluster. If you don’t have a running cluster, you can create one with Minikube.

To install Cyclops in your cluster, run the commands below:

kubectl apply -f https://raw.githubusercontent.com/cyclops-ui/cyclops/v0.20.1/install/cyclops-install.yaml && kubectl apply -f https://raw.githubusercontent.com/cyclops-ui/cyclops/v0.20.1/install/demo-templates.yaml

It will create a new namespace called cyclops and deploy everything you need for your Cyclops instance to run.

Now all that is left is to expose the Cyclops server outside the cluster:

kubectl port-forward svc/cyclops-ui 3000:3000 -n cyclops

You can now access Cyclops in your browser on http://localhost:3000.

Install Cyclops MCP​

1. If you are running Cyclops v0.20.1 or above, you can install the Cyclops MCP by going to the sidebar "Addon"> "MCP server". You can now click "Install Cyclops MCP server", and your Cyclops MCP server will be up and running in a few seconds.

   

   Alternatively, if you are running a Cyclops version before v0.20.1, the Cyclops MCP can be installed with the following command:

   kubectl apply -f https://raw.githubusercontent.com/cyclops-ui/mcp-cyclops/refs/heads/main/install/mcp-server.yaml
   

2. Now that your MCP server is up and running, all that's left is exposing it outside of your cluster and connecting your AI agent to it.

   To expose the MCP server on localhost, you can simply port-forward it with the following command:

   kubectl port-forward -n cyclops svc/cyclops-mcp 8000:8000
   

   Your server is now available on localhost:8000.

3. To connect it to an AI agent, you will just have to provide the Cyclops MCP server in its configuration. For example, to add it to Cursor, you can add it with the following JSON:

   {
     "mcpServers": {
       "mcp-cyclops": {
         "url": "http://localhost:8000/sse"
       }
     }
   }
   

4. You can now start a fresh conversation with your AI companion. Below is an example of how we used it with cursor. You can always see all of the deployed applications in Cyclops and edit them from the UI as well.

Kubernetes MCP​

Before wrapping up, there is one question we have to get straight: “Is there a Kubernetes MCP server I can use to talk to my cluster directly?” - There is!

However, there is a big caveat here. With implementations of Kubernetes MCP, you will let your AI agents deploy lower-level resources like Deployments, Services, Ingresses, and so on. Each company (or even Kubernetes cluster) will have its specifics on what tech to use and how one should deploy their application.

When you tell your agent to “Expose my application outside of the cluster.”, it can do it in a variety of ways. The AI agent could just spawn new Ingresses, but that might not be the way it exposed another application a week ago, leading to inconsistency in the cluster.

The agent will not follow best practices while deploying an application, which could lead to misconfiguration, production outages, or security breaches.

Kubernetes is complex, and how it’s set up varies from cluster to cluster - because of that, AI agents can’t always give you the right configuration for your case.

Final thoughts​

We believe that AI is finding its place in the developer workflow, but there should be levels of abstractions and validations to enable it and make it as safe as possible. This is our first step in this direction.

We built this open-source; feel free to try it out and let us know what you think! Join our Discord and help shape the discussion around AI and Kubernetes 🙌

⭐ Star Cyclops MCP on GitHub ⭐

In many companies, the “right way” to do things - like deploying a new service - is often unclear and undocumented. Instead of a clear process, developers end up asking around, getting bounced from teammate to teammate, until they find someone who might know the answer. That someone, usually a DevOps or platform engineer, is frustrated because it’s the third time this week they’ve answered the same question. At scale, this quickly falls apart.

Netflix uses the term Paved Road, and Spotify uses Golden Path, but in the end, they are the same thing. It is an opinionated guide - a set of tools and tutorials that guide you from idea to production. It helps developers follow the organization’s best practices for building, deploying, securing, and maintaining software.

Today, golden paths have become the cornerstone of platform engineering. In this blog post, we will explore what a good golden path looks like and show an example of it in the wild!

Support us 🙏​

We know that Kubernetes can be difficult. That is why we created Cyclops, an open-source framework for building developer platforms on Kubernetes. Abstract the complexities of Kubernetes, and deploy and manage your applications through a customizable UI that you can fit to your needs.

We're developing Cyclops as an open-source project. If you're keen to give it a try, here's a quick start guide available on our repository. If you like what you see, consider showing your support by giving us a star ⭐

⭐ Star Cyclops on GitHub ⭐

Why Golden Paths?​

Golden paths reduce the mental overhead that developers face. In today’s world, spinning up a new service often means touching infrastructure, figuring out how to set up monitoring, dealing with security concerns, and getting through compliance hoops.

And picking the right tools for the job is also not remotely easy. A golden path walks you through all that and allows the developer to focus on shipping things rather than figuring out how all the tools and processes work together.

For developers, this translates into a faster, happier experience. Less time wasted on boilerplate and tribal knowledge. Fewer mistakes. More focus on building features.

And for organizations trying to scale their DevOps efforts across many teams, golden paths provide a way to extend DevOps capabilities without creating bottlenecks. Everyone moves faster, more safely, and more independently.

The term “Golden Path” was originally coined by Spotify, but it has its roots in the science fiction novel - Dune, where it represents the only future in which humanity avoids extinction 😬

What does a good Golden Path look like?​

No two Golden Paths are identical. Still, most of them are built around a shared set of guiding principles.

The goal is to reduce the cognitive load for developers (or whoever else the target audience may be). By abstracting unnecessary complexity and offering getting-started documentation, developers can focus on solving problems rather than wrestling with setup.

A well-designed Golden Path serves a specific purpose. Instead of presenting developers with a buffet of choices, it offers a single, clear, and opinionated way to get something done that reflects the best practices of the organization.

It is important that they are fully self-serviceable. Golden Paths should be discoverable and usable by anyone in the organization without needing to file tickets or wait for someone to provision resources manually.

And finally, golden paths should be optional. However, if you make best practices the most convenient option, developers will follow them.

Golden Paths and Internal Developer Platforms​

Golden paths are tutorials. Internal developer platforms are golden paths made manifest.

Netflix has a great example of this. Their teams have to go through a checkbox of security best practices when building services. However, they built their own platform (called Wall-E), which allowed developers to bootstrap new services easily with the best security practices already integrated.

Their platform, Wall-E, didn’t just tell developers what to do - it did it for them. It made following security best practices the default, not a checklist. A good developer platform bakes the Golden Path into the developer workflow.

When it comes to implementing an IDP, you have two options: buy one off the shelf or build it yourself (like Netflix did). Both come with benefits and drawbacks. Buying one can be faster, but you will eventually outgrow it. Building one is preferable, but it takes time and resources.

However, building one doesn’t have to be from scratch. In fact, most top-performing teams leverage a combination of open-source and vendor tools (the data). You can use an open-source tool like Cyclops to get you most of the way there! Check out how we use your Helm charts to build internal developer platforms in a jiffy!

⭐ Star Cyclops on GitHub ⭐

Helm is great…

…until you give it to a developer.

The fact is, Helm was made for people who understand Kubernetes. As a DevOps engineer, you can define complex deployments, manage environment-specific configs, and reuse logic with templating. Beautiful.

But for most developers, Helm charts are just confusing. Helm assumes a certain level of Kubernetes fluency that many developers simply don’t have. And that’s okay. They should be focused on building and shipping products, not worry about the underlying infrastructure.

This, however, causes friction since developers become overly reliant on DevOps engineers for every small change and deployment.

Helm is great, just not as a user interface.

But let’s fix that! In this post, I’ll show you how to turn any Helm chart into a simple UI that your devs (or even non-tech folks) can actually use. It won’t take longer than 5 minutes.

Ready, set, go ⏳

#1 Cyclops 👁️​

Cyclops is an open-source tool that allows you to build internal developer platforms from your Helm charts. Basically, you import a Helm chart, and Cyclops spits out a UI based on it.

From there, developers can use this UI to configure, deploy and manage their applications running in a Kubernetes cluster.

The setup is straightforward and just consists of two commands to get you started. You can find it on our webpage or the repository, but I’m also putting it here for easy access:

kubectl apply -f https://raw.githubusercontent.com/cyclops-ui/cyclops/v0.18.2/install/cyclops-install.yaml && 
kubectl apply -f https://raw.githubusercontent.com/cyclops-ui/cyclops/v0.18.2/install/demo-templates.yaml

To access the cyclops-ui you can just port-forward its service, but for production usage you can expose it via an ingress or a load balancer.

kubectl port-forward svc/cyclops-ui -n cyclops 3000:3000

You can now access Cyclops at http://localhost:3000/.

While you are at our repo, consider supporting us with a star!

⭐  Star Cyclops on GitHub ⭐

#2 Grab your Helm chart 🗃️​

You probably have some Helm charts lying around; they will do just fine. If not, you can use mine! I created a chart using the helm create command and haven’t made any changes to it yet.

Let’s take a moment and get a closer look at the chart. It consists of 5 resources: a deployment, a service, a service account, an ingress, and a horizontal pod autoscaler. The HPA and ingress are disabled by default, but you can turn them on in the values.yaml.

The values file is pretty small here, but, even though this is just the “default” Helm chart, it is enough to turn away most developers.

my-chart/
├── Chart.yaml                   # Metadata about the chart (name, version, etc.)
├── values.yaml                  # Default configuration values
├── **values.schema.json**           # Generated from the values.yaml
├── templates/               
│   ├── deployment.yaml
│   ├── hpa.yaml                 # Off in default values
│   ├── serviceaccount.yaml.  
│   ├── service.yaml
│   ├── ingress.yaml             # Off in default values 
└── .helmignore              

I will be using and playing around with this chart, but you can do the same with any of your existing charts.

I’m going to add one more thing to the chart - a schema file. While my Helm chart did not come with a schema file, your chart may already have it (you can see it in the structure above as the values.schema.json). I autogenerated mine and removed the excess lines I didn’t need. You can see the final version here.

#3 Magic 🧚​

Now comes the fun part.

If you have Cyclops set up, open it up in your browser. You will be greeted by the empty Modules screen, but we should first go to the Templates tab.

Out of the box, Cyclops comes with a bunch of templates to help you get started, but let’s add our own so that we can play around with it.

Click the Add template reference button and input the fields so it points to your Helm chart.

⚠️ If you are using a Helm chart that is stored in a private repository, you can find here how to enable access ⚠️

After you have added your chart, go back to the modules tab. It is still an empty screen, but let’s use our new template to deploy a module!

The first step of deploying a module is choosing a template. In the dropdown, find the template that you imported and click on it. Remember the value.schema.json from before? That’s precisely what Cyclops uses to render the UIs.

As you can see, the fields here correlate with the fields defined in the value.schema.json. Changing the schema in the Helm chart, for example removing a couple of fields like here, will result in a different UI as well.

Cyclops is not just a pretty UI for your Helm charts, though. Once you fill in the form your template renders, you can deploy it as a module! Cyclops can either deploy it directly to your cluster or, if you are more of a GitOps enjoyer, push the configuration to git. The end goal is the same: you will have deployed your Helm chart to the cluster using the values provided in the UI.

From here, a developer can easily access everything they might need: restarting their applications, accessing their logs, checking their status, editing the configuration, and much more…

You’re a Platform Engineer, Harry 🧙‍♂️​

While the Helm chart might have been a turn-off for most developers, a simple UI will be far better received. By abstracting away the complexity of Kubernetes and surfacing only the relevant configuration options through a UI, you’ve enabled a safer, faster, and more autonomous workflow for developers.

No more back-and-forth with DevOps for routine changes. No more context-switching to learn Helm. Instead, developers get a streamlined, focused experience that lets them ship their code with confidence. This is the core idea behind Platform Engineering: providing a standardized, self-service infrastructure that empowers development teams.

If you want to learn more about platform engineering and building internal developer platforms, join our Discord community and come talk to us!

⭐ Star Cyclops on GitHub ⭐

There’s been a quiet shift happening in engineering teams over the last few years. DevOps isn’t going away, but it is evolving. More and more companies are moving toward Platform Engineering, and honestly, it makes a lot of sense.

The goal is still the same: help developers ship faster and more reliably. But the approach is different. While DevOps emphasizes collaboration between devs and operations teams through shared responsibility, Platform Engineering seeks to build products that abstract the complexity away from developers. These products are often called Internal Developer Platforms.

Because internal developer platforms come in different shapes and sizes, it can be difficult to provide a clear answer to “Why do I need it?” Their value varies from organization to organization, but I believe the benefits could be grouped into two major categories: developer experience and time to market.

Support us 🙏​

We know that Kubernetes can be difficult. That is why we created Cyclops, an open-source framework for building developer platforms on Kubernetes. Abstract the complexities of Kubernetes, and deploy and manage your applications through a customizable UI that you can fit to your needs.

We're developing Cyclops as an open-source project. If you're keen to give it a try, here's a quick start guide available on our repository. If you like what you see, consider showing your support by giving us a star ⭐

⭐ Star Cyclops on GitHub ⭐

Developer Experience​

Developer experience is closely tied to productivity. When developers have access to clearly defined golden paths, they don’t waste energy figuring out how to deploy something or what’s considered “the right way” to do things.

The same goes for DevOps engineers. Instead of acting as a “help desk” for developers every time something needs to be deployed (no matter how small the change may be), they can focus on more important and less repetitive tasks - improving stability, performance, and managing infrastructure costs.

Increasing the developer experience is not only important for productivity but it has also been discovered to boost developer retention! For example, when Spotify built its own internal developer platform (known as Backstage), they realized that their developers were 5% more likely to stay at the company one year later. Having less fluctuation in developers shouldn’t be easily discarded!

A recent DORA study found a link between IDPs and burnout! One of the explanations is that organizations that struggle with developer burnout build IDPs to combat it.

Time to Market​

Simply put, time to market is the amount of time it takes to go from having an idea to actually delivering a working product or feature to users. Internal platforms dramatically accelerate time to market. The faster developers can ship, the faster the company can grow.

This is something companies of all sizes should aspire to. From startups that want to quickly introduce new features and test ideas on their users, to large enterprises that have rigid processes which slow them down. Having an IDP that provides golden paths for everyone makes the shipping process much smoother.

Faster shipping enables fast iteration, safer experimentation, and more frequent releases. This creates a feedback loop where velocity drives more learning, which leads to better features and better outcomes. In simpler terms, faster time to market means more revenue for the company.

… therefore, we win on engineering velocity above everything else.

There’s so much to ship. the more we ship, the more reasons people have to use us.

Even when we build the wrong thing or ship something that doesn’t work well, we learn the clearest lessons from something we shipped, not something we hypothesized about…

~ James Hawkins co-CEO of PostHog 🦔

Bonus Category?​

There is a third possible category of benefits, which would be infrastructure cost management. But again, that depends on the type of platform you are building and how your current processes look like.

When it comes to implementing an IDP, you have two options: buy one off the shelf or build it yourself. Both come with benefits and drawbacks. Buying one can be faster, but you will eventually outgrow it. Building one is preferable, but it takes time and resources.

However, building one doesn’t have to be from scratch. In fact, most top-performing teams leverage a combination of open-source and vendor tools (the data). You can use an open-source tool like Cyclops to get you most of the way there! Check out how we use your Helm charts to build internal developer platforms in a jiffy!

⭐ Star Cyclops on GitHub ⭐

TL;DR: The Internal Developer Portal is the interface to the Internal Developer Platform. That's it. You can go now.

When researching Platform Engineering, you'll inevitably come across the acronym IDP.

Depending on the source - whether it's a research paper, blog post, or any other piece of content - IDP can refer to either an "Internal Developer Portal" or an "Internal Developer Platform." While these terms are often used interchangeably, they actually describe two distinct things with different purposes and functionalities.

To clear up the confusion, I'll show you real-world examples of both an Internal Developer Portal and an Internal Developer Platform so you can see exactly how they differ in practice.

Support us 🙏​

We know that Kubernetes can be difficult. That is why we created Cyclops, an open-source framework for building developer platforms on Kubernetes. Abstract the complexities of Kubernetes, and deploy and manage your applications through a customizable UI that you can fit to your needs.

We're developing Cyclops as an open-source project. If you're keen to give it a try, here's a quick start guide available on our repository. If you like what you see, consider showing your support by giving us a star ⭐

⭐ Star Cyclops on GitHub ⭐

What are Internal Developer Platforms?​

A developer platform is a product built by the platform team to support application developers and the broader engineering organization. Because these platforms are designed for internal use, they’re often referred to as Internal Developer Platforms.

An internal developer platform often refers to a multitude of tech and tools that are working together to form golden paths - predefined, opinionated workflows that guide developers toward best practices while abstracting complexity and reducing cognitive load.

The platform’s features and use cases should be shaped by what developers actually need, whether that’s provisioning infrastructure, spinning up environments on demand, or maintaining a centralized catalog of services.

At its core, a developer platform should be a force multiplier, helping teams ship faster by eliminating friction and optimizing workflows.

💎 In the past, I’ve used a Minecraft Server together with Cyclops to create an example of what a good internal developer platform looks like. Check it out here 💎

What are Internal Developer Portals?​

An Internal Developer Portal is the interface to the Internal Developer Platform. If the platform is the backend, then the portal is the front-end layer that provides an intuitive way for developers to interact with the platforms capabilities.

The portal acts as a single entry point where developers can perform tasks. While an Internal Developer Platform does the “heavy lifting” in the background, the portal makes its capabilities accessible through a well-designed UI or API.

This distinction is crucial. Without a portal, an Internal Developer Platform is still usable, but it would likely require developers to interact with it through CLI commands, YAML files, or multiple disconnected tools. The portal removes this friction, making it easy for developers to navigate and use the platform.

🎭 Many teams build their own Internal Developer Portals tailored to their needs, but open-source solutions like Backstage have gained traction as a foundation for building these interfaces. 🎭

Backstage & Cyclops​

If we are talking about portals, the most well-known is Backstage. It is an open-source framework for building internal developer portals originally developed by Spotify. It provides a centralized service catalog and helps you manage your documentation.

Backstage is called a framework because of its extensibility with its plugins feature. Plugins are a way for you to integrate your other tooling into the Backstage portal. There is a whole marketplace of plugins developed and maintained by companies that wanted to integrate with Backstage, but you can also create your own!

This plugin ecosystem, coupled with the Backstages portal, allows developers a single point of access to everything they need.

Cyclops, on the other hand, is designed specifically to manage applications on Kubernetes. Cyclops is an open-source tool for creating UIs on Kubernetes enabling self-service for developers. It allows developers to configure, deploy, and manage their applications.

Since Cyclops focuses on a specific layer of a developer platform, it can work well with other tools focused on different aspects. So, it made perfect sense for us to create a plugin for Backstage!

For example, DevOps engineers use Helm to create reusable configuration templates, use Cyclops to provide intuitive UIs for developers and enable self-service deployment and management of their applications, use Prometheus and Grafana to monitor system health and trigger alerts, use Kubernetes as the orchestrator, and finally, wrap it all in the Backstage Portal to offer a unified developer experience.

It’s not 🤜 🤛, it’s 🤝​

So, internal developer portals are the interfaces to the internal developer platforms. They are often used interchangeably because they are part of the same system. By referencing one, you are referencing both of them.

Platforms and portals come in various shapes and sizes. The most well-known framework for building developer portals out there is Backstage, while Cyclops is a framework for building developer platforms. Since the release of the Cyclops plugin for Backstage, you can combine the two!

The release of the Cyclops plugin is part of our launch week here at Cyclops. We are revealing a new feature every day and will end the week with a Product Hunt launch on Friday the 14th of March!

If you find value in what we’re building, consider supporting us on Product Hunt when we launch! Your feedback means a lot to us 🧡

🚀 Support Cyclops on Product Hunt 🚀

GitOps has changed how teams manage infrastructure and deployments, making everything more automated, predictable, and version-controlled. But a question popped up in our mind: Can we make it better?

We are in the business of building Internal Developer Platforms (learn more about them here). One of the core values of IDPs is allowing developers to move as fast as possible with as much safety as possible. However, we realized that the traditional GitOps workflow was creating friction for developers.

In this post, I’ll give you a brief history lesson of GitOps - how it started, where we find it lacking, and what we did to push it further…

Support us 🙏​

We know that Kubernetes can be difficult. That is why we created Cyclops, an open-source framework for building developer platforms on Kubernetes. Abstract the complexities of Kubernetes, and deploy and manage your applications through a customizable UI that you can fit to your needs.

We're developing Cyclops as an open-source project. If you're keen to give it a try, here's a quick start guide available on our repository. If you like what you see, consider showing your support by giving us a star ⭐

⭐ Star Cyclops on GitHub ⭐

What is GitOps?​

A prerequisite to GitOps was infrastructure as code. Instead of manually accessing machines that acted as your servers and then using CLI commands to start your applications on them, things like Kubernetes, Terraform, and others have evolved. They allowed you to define your infrastructure as code, which meant that you had a wanted state of your infrastructure written down - like Kubernetes manifests.

As infrastructure as code grew in popularity, so did the need to collaborate on this code. Slowly but surely, the common best practices used in regular code development were getting adopted in the infrastructure as code space as well.

This meant using git as a single source of truth.

Using the git version control to see who changed what and when.

Making rollback as easy as git revert.

Enabling collaboration through pull requests and code reviews.

Automating code tests and deployment of infrastructure as code.

And thus, GitOps was born. In short, your git repository represents the cluster state, and a GitOps operator is constantly working on keeping the cluster state in sync with the state defined in the git repo.

Fun fact: There are two methods of deploying with GitOps. The push method is where a tool outside the cluster pushes the code into the cluster, and the pull method is where a tool inside the cluster pulls the code into it.

How we took GitOps a step further​

As I mentioned, a prerequisite of GitOps is infrastructure as code. In a typical setup, a company has a repository designated to store infrastructure as code - this can be Terraform, Helm charts, or even plain Kubernetes manifests. Whatever it is, it’s usually under the ownership of a DevOps team.

However, DevOps engineers aren’t the only ones that need to work with this configuration. While infra as code is great for many reasons, product developers aren’t thrilled about it. Product developers understand their applications, but expressing their need in a new coding language is hard (even if it is as “simple” as YAML).

And this often is the most painful part of GitOps. Developers do not understand infrastructure as code and rely on DevOps engineers to either create the code entirely or have a painful PR and review process. This is neither fun for the developers because they don’t understand what they are doing nor for the DevOps because they are playing help-desk for the developers.

But this is where we can take GitOps a step further…

Cyclops​

Cyclops is an open-source tool for building internal developer platforms on Kubernetes. It enables DevOps engineers to create custom UIs on top of Kubernetes and enable self-service for the rest of the developers. Basically, a DevOps engineer can import their Helm chart, and Cyclops will create a UI based on it.

From there, developers can use this UI to configure and deploy their applications. Instead of developers having to learn how Helm charts work (infra as code), they can fill out a couple of fields on the UI, have their input validated, and deploy it with a push of a button.

These fields are created by their DevOps engineers, who have the complete freedom to abstract as much (or as little) of Kubernetes and Helm as they want.

But the cool thing about it is that Cyclops can either deploy this configuration straight to the cluster or push the configuration to a Git repository.

From there, you can use some other GitOps operator to sync these changes back to the cluster, where Cyclops can then manage the application again. Any changes done through Cyclops are pushed to git before being applied to the cluster!

This approach allows you to combine all the benefits of GitOps with the smooth developer experience of a Developer Platform - allowing developers to be fast and independent.

Learn more​

Cyclops is entirely open-source, you can set it up with a single kubectl command, and it comes with a couple of predefined UIs to get you started. You can find a quick start guide on our repository and, while you are there, consider supporting us by starring our repo! To replicate the image above, you can learn more about how to set Cyclops up with GitOps here.

We are also excited to let you know that we are having our second-ever launch week! It will run through 10-14 of March and end with a Product Hunt launch! If you are interested in keeping up, join our Discord or follow us on LinkedIn, where we will reveal a new feature each day of the week! 🤘

⭐ Star Cyclops on GitHub ⭐

Cyclops is having its second-ever Launch Week, starting on March 10th!

Throughout the week, we’ll unveil a new feature of Cyclops every day - five features in total!

Features are not the only thing that we will be announcing. Behind the scenes, we have been making friends in the Kubernetes space...

Come back here each day to see what we launch, or follow us on X and LinkedIn to keep up to date and follow the hashtag #cyclopslaunchweek2

#1 Migrating Helm Releases to Modules♻️​

Cyclops already picks up on any installed Helm releases in your cluster. But when selecting a Helm release, you will notice a new button pop up in the top right corner!

With the release of this feature, you can easily migrate your Helm releases to Cyclops’ modules! (Yes, even in bulk!)

You will simply need to choose a template for your migration, and voila! Your applications will be migrated to Cyclops modules without even noticing. They won’t be redeployed and will continue running like nothing even happened.

But that is not the only news we bring! We are super happy to announce our newly established partnership with Suse! You can now find a familiar face in the Rancher Marketplace and install Cyclops in one click.

#2 Pushing Modules to Git ⏫​

You now have the flexibility to deploy a Module in two ways:

1. Deploy directly to your Kubernetes cluster
2. Push the Module manifest to a Git repository

Simply specify the repository and path where you want to store the configuration, then click Deploy. From there, tools like ArgoCD can take over and deploy the application. Once it's live, Cyclops will automatically detect it and display it in the UI.

When you edit a Module using this workflow, any changes will be pushed to the Git repository, keeping everything in sync.

Check out our updated documentation for more details.

We are also very excited to announce that now you can find Cyclops on the DigitalOcean marketplace! To celebrate, we have published a tutorial in collaboration with DigitalOcean on how you can easily create an internal developer platform on their Kubernetes clusters.

Check it out! 🌊

#3 Backstage Plugin 🧩​

Backstage is a framework for building developer portals built and open-sourced by Spotify.

Developer portals built with Backstage allow you to have a centralized catalog of all applications and services running in your system. All of the applications your developers are working on in a company are listed and organized in a single place.

Another benefit of Backstage is that it centralizes all the tools used for managing software into a single platform, so deployment processes, monitoring, alerting, and so on are all in a single app. This is achieved through Backstage's plugin architecture, and Cyclops implements its own plugin.

With the Cyclops plugin, you can view all of your deployed Cyclops applications and get the full experience of Cyclops in your Backstage instance.

Check our docs on how to set it up for yourself!

#4 Backstage Plugin ✌️​

This launch week, we are releasing not one but two Backstage plugins.

Backstage has a concept of components that represent services and applications in your system so you keep track of your software. In order to allow you to map your components to applications in Cyclops, we released another plugin that is integrated into your component catalog.

Each of your Backstage components will now have an additional tab showing you your Cyclops application with all the Kubernetes resources and allowing you to edit, roll back, or delete your application.

With this plugin, your software catalog allows your developers to deploy their applications and manage the whole lifecycle from a single pane of glass.

#5 Dark Theme 🌙​

We heard you - Dark Mode is here! Cyclops now comes with a sleek dark theme that’s easier on the eyes and perfect for late-night sessions. Simply toggle it in the top right corner and enjoy the new look!

A small change, but an essential one - because let’s be real, no developer can live without Dark Mode! 🌚

That’s it! For now…​

And that’s a wrap on Cyclops Launch Week #2! 🎉

Five days, five big releases - from better Helm migrations to Git integration, Backstage plugins, and now Dark Mode. But this is just the beginning!

We’re excited to hear your thoughts, so try out the new features, give us feedback, and stay tuned - we have even bigger things coming soon. 🎵

Thank you for being a part of ourjourney! If you are interested in keeping up to date, be sure to join our Discord community where we always share the latest news! 👾

If you have been looking for a tool to deploy your applications into a Kubernetes cluster, you have definitely stumbled upon Helm. Its the most common Kubernetes configuration management tool out there.

Helm is a package manager for Kubernetes. This means you can group your deployments, services, ingresses, and all other Kubernetes resources into meaningful units. This means that a software vendor (for example, Grafana) can create a single Helm chart, and all users can simply install a gazillion of resources with a single command, knowing it’s going to work.

I think some parts of Helm are awesome, and some are often misused and introduce complications without much benefit.

If you have some running Helm releases in your Kubernetes cluster, this one is for you!

Support us​

We know that Kubernetes can be difficult. That is why we created Cyclops, an open-source framework for building developer platforms on Kubernetes. Abstract the complexities of Kubernetes, and deploy and manage your applications through a customizable UI that you can fit to your needs.

We're developing Cyclops as an open-source project. If you're keen to give it a try, here's a quick start guide available on our repository. If you like what you see, consider showing your support by giving us a star ⭐

⭐ Star Cyclops on GitHub ⭐

What is Helm?

An application deployed to a Kubernetes cluster is usually not just a Deployment but a list of other Kubernetes resources like Configmaps, Secrets, Ingress, and many others. Instead of manually creating all of them time and time again, you could create a Helm chart that would define all of these resources in a single place, and then you can reproduce them when needed.

A Helm chart is a single Helm package. Grafana has its own Helm chart which defines all the resources you need to run it, MySQL has its own chart, and so on.

If you want to run a MySQL in your cluster you can simply install the chart to your cluster and not think about specific resources. With that installation, you just created a Helm release. Releases track what has been installed in the cluster so you can check what Helm charts you installed later on.

In a Helm chart, Kubernetes resources are defined as templates that allow users to customize them without having to dive into each one. You can customize your releases using the values files that contain configuration, which would be injected into the resource templates to create Kubernetes manifests. And this is where the trouble with Helm begins.

Cons​

I love the way Helm implemented their package management, but there are some things I’m not the biggest fan of.

YAML Configuration​

Helm’s templating engine is great for abstracting and reusing configuration. But each time you encounter a new Helm chart, you will need to spend some time figuring out what you can and can’t configure.

values.yaml is usually a good place to start since there you can find the default configuration. But, not all configuration needs to be defined in values.yaml, and you will need to dig through the docs (if there even is any) or, God forbid, the Helm templates to see how things map between values and templates.

There is no type safety, and you could easily make a typo in your configuration, resulting in an outage.

Configuration Persistence​

When you install a Helm release, Helm will, by default, use values from the values.yaml. You can inject any values from a file or directly with the --set flag while running helm install, but that then begs the question of what is actually deployed. Each time you want to upgrade your Helm release, you need to know exactly what is currently deployed to not override something by accident.

For example, you and your colleague are working on the same application deployed as a Helm release. Your colleague wants to set the number of replicas to 5:

helm upgrade my-release <helm repo> --set replicas=5

After that, you want to bump the version of your application to latest with the following command:

helm upgrade my-release <helm repo> --set image.tag=latest

You deployed a new version, but without knowing it, you have just overridden your colleague's changes and you are back to a single replica. Unless you check for the currently deployed values, you can’t be sure if you are overriding something deployed by somebody else (or even yourself a month ago).

Resource Overview​

Once a release has been installed, you will likely want to check what resources have been deployed and whether they are running as expected. Helm solved it with the helm status command that can list all the resources.

This is more a personal preference, but I find it strange to list deployed resources with the helm cli and then dig deeper with kubectl. Ideally, I could check my resources from a single pane of glass.

Managing Helm Releases with Cyclops

Cyclops natively supports Helm charts and their deployment. It addresses the problems listed above and provides you with a custom UI for all of your Helm charts.

Instead of configuring your Helm charts via YAML, Cyclops will generate a UI based specifically on the Helm chart values. Since you are configuring your app through a form, you can now see all of the fields you can configure and be sure the values you provided are validated.

Instead of relying on Helm releases, Cyclops implements its own Custom Kubernetes Resources called Modules, which reference Helm charts and keep all of your values persisted.

Since version v0.17.0, Cyclops allows you to migrate your existing Helm releases to Cyclops Modules in a non-invasive fashion. It will just create a new Module for your application and delete the release without deleting or redeploying your applications.

Migrate to Cyclops​

Cyclops can automatically pick up on all of your Helm releases currently running in the cluster and offers you the ability to migrate them to Cyclops Modules. A Cyclops Module is a custom Kubernetes resource that references a Helm chart and contains all the values used to configure that chart.

With such an approach, you don’t have to worry about what value files you need to use, how those overlap… Instead, everything is in a single place defined declaratively. If you want to change any of the values, feel free to do it via Module YAML, in the Cyclops UI, or any other way you want.

Let’s migrate those releases!

Install Cyclops​

First of all, you will need to install Cyclops into your running Kubernetes cluster. You can install Cyclops with the command below:

kubectl apply -f https://raw.githubusercontent.com/cyclops-ui/cyclops/v0.17.1/install/cyclops-install.yaml && kubectl apply -f https://raw.githubusercontent.com/cyclops-ui/cyclops/v0.17.1/install/demo-templates.yaml

To access the cyclops-ui you can just port-forward its service, but for production usage you can expose it via an ingress or a load balancer.

kubectl port-forward svc/cyclops-ui -n cyclops 3000:3000

You can now access Cyclops at http://localhost:3000/.

Migrating Helm releases​

For the sake of the tutorial, I installed three Helm charts. If you don’t have any Helm releases installed to try the migration, you can install the official PostgreSQL chart with the following command:

helm install my-api-database oci://registry-1.docker.io/bitnamicharts/postgresql

When you open Cyclops, you can navigate to Helm releases in the sidebar to list what is currently deployed in your cluster.

From there, you can select any of your Helm releases and check Kubernetes resources deployed with that specific release.

When you are ready to migrate your release and use Cyclops modules, click the Migrate to Cyclops Module, which will open a pop-up where you can input the Helm chart reference. In this case, it would be the Bitnami git repo and its PostgreSQL chart on the main branch.

Chart reference can also be a Helm repository or an OCI Helm chart.

Once you confirm the chart reference, Cyclops will pull it to verify it, and if the reference is valid, redirect you to a page where you can tweak the configuration before migrating to a Cyclops module.

Don’t worry; Cyclops will retain the configuration you previously had for your Helm release; this step only allows you to change it if needed.

Once you are happy with your configuration, you can hit Deploy, and Cyclops will create a new Module with your template reference and all of the values you provided.

All previously deployed resources will remain unchanged, and none will be destroyed in the process. The only change that happened is that you now have a Module managing your resources.

With Cyclops, you now have a centralized place for your app configuration and can now view all of your resources and their status in a single place. Also, you and your colleagues are not stepping on each other's toes!

Future work

We at Cyclops plan to expand beyond supporting Helm and want to make our Modules support any kind of configuration language. Let us know what you are using (Kustomize, KPT, Cue…), and we would be happy to support it next!

If you enjoyed this article or found it helpful, join our Discord server, where we always let you know about the latest content, new developments, and news from our team!

⭐ Star Cyclops on GitHub ⭐