A good developer experience is about more than getting a container image running quickly. It's the peace of mind that comes from a platform that remains stable, behaves predictably and shows you what's happening when something goes wrong. That's the standard we hold Cycle to.
We care about this because developer time is one of the most valuable things an engineering team has. Every hour spent wiring up networks or hand-rolling rollback scripts is an hour that didn't go into the product. We see a lot of teams stretched thin by that kind of work, and the features in this walkthrough exist to give some of that time back.
Below, we go through how each feature works in practice, and how the pieces fit together into a workflow your team can grow into.
How can teams utilize Cycle?
There are four primary ways to interact with Cycle, and teams can pick whichever fits their habits. The portal gives you a visual view of everything you run. The API lets you script custom logic and plug Cycle into your own tooling. The hosted MCP lets you work with the platform through AI tools that support the Model Context Protocol. Pipelines and stacks bring Cycle into a GitOps workflow, which we cover further down.
The important detail is that the whole platform shares the same capabilities regardless of how you reach it, so choosing the portal today doesn't lock you out of automation later. Most teams start in the portal to get a feel for how things are organized, then gradually shift toward the API or pipelines as their workflows mature. We like that progression because it lets a team improve its process in small steps instead of committing to one approach up front.
On the MCP side, we see AI as a genuinely useful assistant for things like checking on an environment or pulling up container details. Your engineers still make the decisions about what gets deployed and how, and the MCP is there to help them get answers faster.
What is a Cycle environment?
At its core, a Cycle environment is a globally encrypted network and its associated services. Everything you deploy in it, from containers to virtual machines, stays connected, wherever it runs. Cycle sets up that network automatically, so there's nothing extra for your team to configure.
Every application on Cycle runs inside an environment. The environment also provides services such as load balancing, scheduling and discovery for the containers, virtual machines and functions deployed in it.
When you do want separation, such as keeping a private data store isolated from the applications that use it, you place those workloads in separate environments and connect them with a software defined network. That gives you explicit, controlled links between environments rather than one large flat network.
In the portal, the environment view shows your containers and virtual machines across every provider in one place. From there you can review configuration, sample logs and look at telemetry. When troubleshooting calls for it, you can open the console of a specific instance or shell into it directly, which saves a round trip to a separate tool.
How do deployments and rollbacks work in Cycle?
Deployments let you run multiple independent copies of a group of containers inside the same environment. That opens up a lot of release patterns. You can use deployments for smoke testing a new build, for blue-green releases, or for what we call rainbow deployments, where you run any number of versions side by side and route traffic to whichever one you choose. A common pattern among our customers is spinning up a preview app for every merge request, so reviewers can click through a running version of the change before it ships.
The mechanism that makes this simple is the pairing of versions and tags. Each deployment has a version, and you attach tags such as prod to a version. Tags are unique within an environment, and DNS records can be associated with a tag. For example, if a frontend's DNS record points at the prod tag, the site serves whichever version currently holds that tag.
To shift traffic, you move the tag. For example, you can move prod from the current version to the dev version, apply the change, and the DNS records follow the tag so the frontend starts serving the new version almost immediately. Rolling back is the same action in reverse: move the tag back to the previous version. Because Cycle keeps the previous version running until it is no longer needed, a rollback doesn't require a rebuild or a redeploy, and there is no downtime while traffic moves.
For teams that release often, this turns a rollback into a routine, low-stress operation. That matters for continuous improvement, since teams are far more willing to ship small changes frequently when they know undoing one takes a single step.
How do stacks and pipelines support a GitOps workflow?
Stacks are Cycle's native way to define an environment as code, written in either JSON or YAML. If you've worked with Docker Compose files or Helm charts, the idea will feel familiar. A stack describes your containers and their configuration, along with the other things an environment holds, such as load balancer rules and networks. Traditional infrastructure as code tends to focus on provisioning machines, while stacks focus on your environments, configuration and application state. If you already have Compose files, Cycle offers an automatic converter to turn them into stacks.
Pipelines are how you orchestrate and automate container deployments. A pipeline can sequence interactions with most parts of the platform, so you can chain steps like building a new image, deploying it into an environment and then moving a tag once it's healthy.
Put stacks, pipelines and deployments together and you have a GitOps workflow: your environment definition lives in version control, a pipeline applies changes when they land, and tags control which version receives traffic. Both stacks and pipelines have their own deep-dive videos, so we'll keep this overview high level.
See Cycle's developer experience platform in action
For a long time, teams have had two main options for running containers. They could build and operate the whole stack themselves, with full control and a heavy time cost, or they could accept a managed platform that limits what they're able to build. Kubernetes is a great fit for some teams, and we respect the teams who've invested in it. We also talk with many teams who landed there because there weren't real alternatives, and we think they deserve more choice.
We built Cycle as a third path. It's a developer experience platform where environments, networking, deployments and automation come ready to use, and your team still decides where workloads run, whether that's public cloud, bare metal or a mix of both. The features in this walkthrough are a starting point, and each one is designed to give developers a stable, predictable platform they can see into, so they spend less time on infrastructure and more time on the product.
If this overview raised questions you'd like to dig into, schedule a full demo on cycle.io and we'll walk through how Cycle fits your current architecture.
Frequently asked questions
What is a rainbow deployment?
A rainbow deployment is Cycle's extension of the blue-green pattern. Instead of two versions, you can run any number of versions of a group of containers side by side in the same environment and route traffic to whichever one you choose by moving a tag. Older versions stay running until you remove them, which makes rolling back as simple as moving the tag back.
How does a Cycle stack compare to a Docker Compose file or a Helm chart?
The idea is similar: a stack is a JSON or YAML file that describes your containers and how they're configured. A stack also covers the rest of what lives in a Cycle environment, such as load balancer rules and networks, so one file can define the whole environment. If you already use Compose, Cycle offers an automatic converter to turn Compose files into stacks.
Can Cycle run workloads on bare metal and across multiple clouds?
Yes. Cycle lets you deploy to the cloud, on-premises, or both through one control plane. Workloads in the same environment share an encrypted Layer 3 network even when they run on different providers, so a mixed setup doesn't require extra network configuration.
Can containers in different environments talk to each other?
Containers in the same environment communicate automatically on that environment's private network. Containers in separate environments are isolated by default, and you connect them deliberately with a software defined network. This is how teams keep something like a private data store isolated from their applications while still allowing the traffic they need.
Does Cycle handle OS updates and security patches?
Yes. Cycle fully manages the host OS on your servers, and once servers are connected to the control plane they automatically receive updates with new features, bug fixes and security patches. Your team still decides how workloads are exposed and networked, so it's worth understanding those settings even with patching handled for you.