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 ⭐

Before diving into internal developer platforms, it’s important to understand platform engineering first. Platform engineering evolved from DevOps and aims to address the growing complexity of modern software development.

However, while DevOps focuses on bridging the gap between development and operations, platform engineering takes it a step further. The goal of platform engineering is to establish a unified platform that enables developers to move as fast as possible with as much safety as possible.

But why did this trend emerge, and how does it differ from what is currently out there?

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 Developer Platforms​

A lot of the motivation behind building internal developer platforms is centered around the idea of self-service.

When you think of DevOps, you envision automation, pipelines, monitoring, and other Ops-like functions. While most of these things are focused on enabling developers to move faster, in reality, the DevOps team can often feel like a bottleneck.

If you need to raise a ticket with the DevOps team whenever you want to create a new service, change something in the configuration, or have issues with a deployment, it will inevitably slow you down.

On the other hand, the DevOps team doesn’t always want to spend their time reviewing every minor change requested by developers. They’d rather focus on more productive work than act as a helpdesk for routine requests.

A system where every infrastructure and deployment change has to be reviewed and approved by the DevOps team is often called ticket ops

(Internal) Developer Platforms​

A developer platform is a product built by the platform team to support application developers and the rest of the engineering organization. It connects all the tech and tools in a company into streamlined workflows, often called "golden paths," that reduce cognitive load and simplify self-service for developers.

Since these platforms are designed specifically for internal use within an organization, they're often called Internal Developer Platforms.

A developer platform can take many forms. From a documentation page and a couple of bash scripts all the way to fully fleshed-out self-service portals.

A platform's features and use cases should be driven by what developers actually need, whether it's provisioning infrastructure, spinning up environments on demand, or providing a central catalog of services.

At its core, a developer platform should act as a force multiplier, enabling teams to ship faster by removing friction and streamlining workflows.

Just to clarify the distinction between developer portals and developer platforms, a developer portal is simply the interface (typically a GUI) developers use to access the internal developer platform.

Building Internal Developer Platforms​

There are a couple of important things to keep in mind when building an internal developer platform.

The platform is a product, and you should treat it as such. It should be designed around user needs and continuously improved, just like any other software product. Just in this case, the users are your own developers!

A good platform abstracts complexity, reduces the cognitive load for users, and makes it easier for product teams to focus on delivering value rather than dealing with infrastructure.

But in the end, it’s all centered around self-service. Developers should be able to request and provision resources independently and with confidence without relying on manual approvals.

A platform should support the above features and workflows, but just because it provides certain capabilities, it doesn’t mean the platform team has to build everything themselves. In many cases, a lot can be accomplished with the use of external tools (proprietary or open-source).

Learn more ⬇️​

At Cyclops, we’re creating an open-source framework for building internal developer platforms on Kubernetes. We make it easy for you to provide golden paths to your developers by allowing you to create custom UIs from your Helm charts.

If you are interested in learning more about platform engineering, I’m nudging you to check out the CNCF Platforms White Paper, the Internal Developer Platform Org, and the Platform Engineering Org. Hope you find these sources as useful as I did.

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 ⭐

Platform engineering is possibly the biggest concept to take hold in infrastructure over the last 5+ years, and there’s a big reason why. For decades, application engineers have dealt with systems that have constantly thrown roadblocks and delays in their way. Platform engineers address this problem by building systems that enable self-service and provide useful abstractions that help those other engineers build and run their applications. As we know, enabling self-service helps both productivity and developer happiness.

However, building and maintaining a platform can be expensive, and not every organization has the budget for a dedicated platform team. For organizations with platform teams, there’s an ongoing tension between either building custom tools, using open source tools, or buying commercial solutions. Each of those options requires some kind of investment, but for many teams, building platforms largely composed of open source tools is a strong choice. The team doesn’t spend a lot on software licenses and isn’t stuck maintaining all the code.

In this post, we’ll look at Cyclops, an open source tool for building developer platforms. Cyclops lets teams deploy and manage applications using Helm charts as templates.

Prerequisites​

The main requirement for this tutorial is a Kubernetes cluster. In this example, we’ll use kind to provision a cluster, but feel free to use a different method if you prefer. If you’re not already using kind, you can install it using the instructions in the docs. You also need a local Docker-compatible daemon to use kind, like Docker, Podman, or Colima.

You will also need kubectl. You can find instructions for installing kubectl in the Kubernetes docs.

Provision a cluster and install Cyclops​

First, provision a cluster.

kind create cluster --name cyclops-demo

Your kube context should already be set to point to the kind cluster. You can test that you can connect by viewing the namespaces in the cluster.

kubectl get namespaces

Next, install Cyclops into your cluster with kubectl.

kubectl apply -f https://raw.githubusercontent.com/cyclops-ui/cyclops/v0.15.4/install/cyclops-install.yaml

As you’ll see from the output, Cyclops is composed of Kubernetes native objects.

customresourcedefinition.apiextensions.k8s.io/modules.cyclops-ui.com created
customresourcedefinition.apiextensions.k8s.io/templateauthrules.cyclops-ui.com created
customresourcedefinition.apiextensions.k8s.io/templatestores.cyclops-ui.com created
namespace/cyclops created
serviceaccount/cyclops-ctrl created
clusterrole.rbac.authorization.k8s.io/cyclops-ctrl created
clusterrolebinding.rbac.authorization.k8s.io/cyclops-ctrl created
deployment.apps/cyclops-ui created
service/cyclops-ui created
networkpolicy.networking.k8s.io/cyclops-ui created
deployment.apps/cyclops-ctrl created
service/cyclops-ctrl created
networkpolicy.networking.k8s.io/cyclops-ctrl created

There should now be two pods running in a new namespace called Cyclops. We can view them with:

kubectl get pods -n cyclops

You should see output like this:

NAME                            READY   STATUS    RESTARTS   AGE
cyclops-ctrl-7984df7589-wv4dw   1/1     Running   0          36s
cyclops-ui-64c4cdd7f7-fxnb7     1/1     Running   0          36s

The first pod handles the Cyclops API, manages the CRDs, and communicates with the Kubernetes API server. The second pod runs the Cyclops web UI.

Next, we will install a set of example templates that we will use to see how Cyclops works.

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

Finally, let’s connect to the Cyclops web UI. First, forward a port to it using kubectl.

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

Next, connect to the UI with your browser at http://localhost:3000/.

Deploy Nginx with a generic app template​

For the first portion of the demo, we’ll deploy Nginx using Cyclops.

Open a new terminal window/tab and create a namespace called nginx.

kubectl create namespace nginx

Now, go back to the Cyclops UI tab in your browser. Click Add module in the upper right corner of the Cyclops screen. Think of a module in Cyclops as an application and all of the other Kubernetes resources required to run it.

Next, we’ll select a template. Cyclops templates are Helm charts, and Cyclops can use charts from GitHub repositories, Helm chart repositories, or OCI repositories.

Select app-template from the Template pull-down list. This generic template creates a Kubernetes deployment and service for an application.

For the module name, enter nginx. Click on Advanced. Select the nginx namespace from the Target namespace pull-down menu.

Click on General. You can see that some defaults have been populated, like the image name version. Leave them set to the defaults. Those values are being pulled from a values.yaml file in the Helm chart.

You’ll see some other configurable options under Scaling and Networking. You can also leave those set to the defaults. Scroll down and hit the Deploy button in the bottom right of the window.

On the next screen, you’ll see more information about the module and its status as it’s deployed. There’s a link to the template it was deployed from and information about the Kubernetes resources that have been created.

Click on nginx Deployment to see that one pod is running. We can confirm that info in the terminal by running this command:

kubectl get pods -n nginx

That output should match what you saw in Cyclops.

Go back to the Cyclops browser tab. Under Actions, you can see several buttons for making changes to a running module. Edit will let you change the configuration. Reconcile will re-create the resources. Rollback will revert to the previous version of the module if you have made changes. You can view the code for the module using the Module manifest button, and Rendered manifest lets you view the Kubernetes YAML for the running resources.

Click Edit, and then change the number of replicas to 2 under Scaling. Then, hit the Deploy button.

Once the status goes back to green, hit the Rollback button. You’ll see a list of the module's previous generations (versions). There should just be one. Click the Rollback button for that generation, and you’ll see a diff of the changes that were made.

Click the OK button to perform the rollback.

Some teams won’t want to manage changes through the Cyclops UI, of course. You can instead use Cyclops with GitOps tools like Argo CD. There’s a GitHub repo with examples here.

Finally, let’s clean up. Click Delete, and type in the module name to confirm.

Deploy Redis with Cyclops​

We’ve seen how to deploy an app with a custom Helm chart, but Cyclops can also deploy applications using existing Helm charts. Let’s look at how that works by deploying Redis using the Bitnami chart, which is included with Cyclops.

At the terminal, create a namespace called redis.

kubectl create namespace redis

In the Cyclops browser tab, click Templates in the left nav bar. Type “redis” in the search box to see the info for the installed template. The source for it is the Bitnami GitHub repo, and it’s coming from the main branch.

No, click on Modules in the left nav and then Add module again. Select redis from the module pulldown list, and type in “redis-cache” for the module name. Click on Advanced and select redis from the list of namespaces.

Scroll down. You will see many other options that can be customized for the Redis install. Feel free to expand and view any that interest you, but leave them set to the defaults. Then, click the Deploy button in the bottom right.

It may take a bit for Kubernetes to spin up all the resources, but eventually, they should all go green.

We can confirm the pods are running with this command:

kubectl get pods -n redis

You should see the primary/master node and three replicas like this:

NAME               READY   STATUS    RESTARTS   AGE
redis-master-0     1/1     Running   0          4m6s
redis-replicas-0   1/1     Running   0          2m21s
redis-replicas-1   1/1     Running   0          3m10s
redis-replicas-2   1/1     Running   0          2m46s

We can use any Helm chart with Cyclops like this to allow users to deploy the applications they need to run. In the case of a complex module like this one, you can set default values that are needed for your team or even create a custom Helm chart that exposes fewer options.

That’s it for the tutorial. To clean up, you can delete the kind cluster.

kind delete cluster -n cyclops-demo

Conclusion​

We’ve learned how to deploy applications with Cyclops using pre-existing Helm charts and custom ones, and we’ve seen how Cyclops allows teams to easily expose the abstractions they need for developers to deploy and manage their apps.

Whether you’re at an organization that’s not staffed for a dedicated platform team or your platform team would like an easy way to provide self-service for developers, Cyclops could be a great fit for your workflow.

Learn more​

• The Cyclops docs are a great place to start.
• Check out their open-source repository and support them with a star.
• There’s a community Discord if you’d like help or to give your feedback.

To start this off, I want to say that I’m not some sketchy betting tips dealer and to be honest, I don’t even watch sports. But I want to share why we’re placing a big bet, a startup-sized bet, on Kubernetes (and we are not the only ones doing it).

And no, it’s not what you think. We’re not just using Kubernetes as part of our tech stack. It’s not that simple. Our entire startup depends on the success of Kubernetes. We are literally all in, and I want to tell you why we feel comfortable with that decision.

I have a couple of important points I want to lay down, and I hope they’ll give you a clear picture of why Kubernetes is not just a safe bet for us but an inevitable one.

It’s Open-Source​

The first thing I need to mention is that Kubernetes is open-source and supported by a massive, active community. On GitHub, it boasts over 112K stars.

Being open-source has cultivated a thriving community around it, and I don’t mean that as a buzzword. There’s an incredible amount of content available - blogs, tutorials and videos. While Kubernetes is famously complex, the wealth of resources online makes it far more approachable.

But it doesn’t stop at educational content. Kubernetes’ open-source nature has also enabled an extensive ecosystem of tools, integrations, and extensions, from Helm charts to advanced monitoring tools like Prometheus. Tools like these emerged to fill the gaps in Kubernetes, moved it towards widespread adoption, and have become almost a core part of it.

It’s Battle-Tested​

The first commit of Kubernetes was pushed to GitHub on June 6th, 2014, which was more than ten years ago.

Since then, it has seen a massive rise in popularity. Not only can you run Kubernetes on your home lab, but every major cloud provider offers a managed version of Kubernetes. Over the years, it has gained the status of “production-ready” and is now the most popular container orchestrator. In 2021, there were 5.6 million developers that use Kubernetes worldwide; today, that number is undoubtedly even higher.

It’s the platform for building platforms​

“Kubernetes is a platform for building platforms. It’s a better place to start; not the endgame.” ~ Kelsey Hightower

One of the most fascinating aspects of Kubernetes is that it’s not just a tool for managing containers - it is an extensible API.

The creators and maintainers of Kubernetes have had great foresight when creating the architecture and design patterns for it. Kubernetes allows you to extend its base functionality with your own custom operators and resources.

Apples 🍏​

Let’s say you want Kubernetes to manage something completely unrelated to containers—like apples. By defining a Custom Resource Definition (CRD) for apples, you can “teach” Kubernetes to recognize them as a resource type. Kubernetes is now not only a manager for deployments and pods, but for apples, oranges, or whatever else you want. Once that’s done, you can use native Kubernetes commands to interact with your apples:

kubectl get apples

NAME          AGE
green-apple   6s

This silly example shows the power of Kubernetes’ extensibility. By defining apples as a custom resource, you make them behave like any native Kubernetes object. This means you can manage them declaratively (e.g., creating or updating their desired state) and enjoy Kubernetes’ core features, like self-healing, scaling, reconciliation loops...

You can imagine that instead of apples, you are interacting with databases or S3 buckets. Now, suddenly, you can use Kubernetes to provision infrastructure instead of just managing your applications.

This is a very powerful concept.

So, what are we betting?​

At Cyclops, we are creating an open-source framework for building developer platforms on Kubernetes.

We believe that Kubernetes is not just a trend - it’s the future of building cloud-based services. As the ecosystem matures, Kubernetes is quickly becoming the standard for managing and orchestrating workloads in the cloud.

We’re betting on Kubernetes becoming the foundation for developer platforms. More and more companies are interested in building custom developer platforms that empower their teams. These platforms streamline workflows, simplify the development process, and provide tailored tools for their unique needs (learn more about platform engineering).

We are betting on companies building developer platforms on top of Kubernetes, and we want to help them on this journey.

By the way… 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 ⭐

If you are confused about what DevOps or Platform Engineering even is, you are not alone. There is a lot of online discussion around this topic, and depending on who you ask, you might get different answers.

Part of the confusion comes from DevOps being often used as a catch-all term. Even Wikipedia is confused about what DevOps really is:

…academics and practitioners have not developed a universal definition for the term "DevOps." ~ Wikipedia

But I'm here to tell you that there is a difference between these two. Let's start by defining them and then see how are they connected…

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 DevOps?​

DevOps is not actually a job role, it’s a philosophy. The Dev in DevOps represents software development, such as building applications and features, and the Ops stands for operations, which usually represents pushing, running, and maintaining the software on your servers and infrastructure.

DevOps as a Philosophy​

Consider this: you have a developer team in charge of shipping out applications and features, and you have an operations team in charge of taking that software and running and maintaining it on your infrastructure.

When a bug reaches production, who’s at fault here? Development teams often blame operations for deployment failures, while operations blame developers for writing unstable code.

And these teams have different goals to keep up with. Devs want to ship as much code as fast as possible, while the Ops team prioritizes stability and reliability. This “siloed“ culture causes tension and inefficiency.

This was the reality before DevOps became mainstream (and in some cases, it still is). DevOps as a philosophy promotes a collaborative culture where developers and operations teams work closely together throughout the software development lifecycle. Instead of throwing software "over the wall", both teams share responsibility for building, deploying, and maintaining the software.

DevOps as a Job Role​

I know I said that DevOps is not actually a job role, but in reality, it has become one. While the original term might have meant restructuring organizations to bring the development and operations teams working more closely together, in today's world, it represents a job role akin to Ops.

A DevOps is basically someone who implements things such as automations and CI/CD processes, handles infrastructure, and monitors the metrics of applications. The role can have various responsibilities, but the focus is on enabling teams to build, test, deploy, and monitor their services (this is where the philosophy shines through).

In this role, you will collaborate with development, operations, and infrastructure teams to automate and streamline our processes, build and maintain tools for deployment, monitoring, and operations, and troubleshoot and resolve issues in our development and production environments. ~ a job listing for a DevOps engineer

What is Platform Engineering?​

Platform engineering acts like an internal product team, but instead of serving external customers, its primary users are the company's own developers and internal teams.

The job of platform engineers is designing and building toolsets, infrastructure, and workflows that make it easier for developers to build, test, deploy, and manage software. The goal is to create a unified platform, often called an Internal Developer Platform (IDP), which provides developers with self-service access to everything they need without depending on other teams, like operations or infra.

You will build platform tools and leverage innovative cloud technology to bring joy to your end users - < company's > developers. You are a builder that’s passionate about multiplying our engineering force through automation, cloud technologies, and productivity tools, which enhance the developer experience. ~ a job listing for a Platform engineer

How are they related?​

Platform engineering is not a replacement for DevOps. The goal of DevOps is to improve software quality, speed of iteration, and delivery, which is usually achieved by adopting new tools and workflows. In that regard, Platform engineering is one of the ways to implement and manifest DevOps principles.

The line between the two is usually drawn on the internal developer platform (IDP). While DevOps engineers do build tools for developers (like bash scripts) and try to automate as much as possible, the goal isn’t centered around one specific product.

Platform engineering does have a product at its core - the developer platform, which removes as many obstacles as possible to make developers as autonomous and as fast-moving as possible.

The new kid on the block​

Platform engineering is a relatively new concept, with one of the most famous examples being Backstage. But, building an internal product (the IDP) is a very expensive endeavor for organizations. You won’t see many job listings for platform engineers in smaller companies (a DevOps position is more common here).

At Cyclops, we’re creating a framework for developer platforms that reduces the cost and time needed to build Internal Developer Platforms (IDPs). We want to bring all the benefits of IDPs to companies of any size.

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 ⭐

PS: Oh, and no shade to Wikipedia, I love them 🧡 ~ Juraj