Stateful and Stateless Containers on Cycle

Cycle aims to give you maximum flexibility with how you architect your application. By marking a container as ‘stateful’, you’re declaring that the container and its instances should be treated more like pets than cattle, but more on that analogy below.

The need to maintain state should never be a deciding factor when considering whether or not to containerize as containers are simply portable code packages.

Pet vs Cattle

An analogy that gets thrown around often within the DevOps and infrastructure world refers to applications and servers as either pets or cattle. The idea behind the analogy is that you give special preference and care to pets where cattle are treated as more disposable. If a ‘pet’ application or server becomes unhealthy, you nurse it back to life. A ‘cattle’ application or server, on the other hand, is destroyed and reinitialized rather than spending time trying to nurse back to health.

pets cattle


A stateful instance is treated as a pet. If something happens to the instance, it needs to be nursed back to health. The long term health of this instance is of maximum importance.

Typically, stateful applications are those that care about data persistence across restarts. Additionally, they typically need started in a specific order or stopped gracefully.

Use Cases

  • Databases
  • File/Object Storage
  • CMSes (WordPress, Drupal, Magento)

Stateful on Cycle

Marking a container as stateful on Cycle opens up the following options.

  • Provide additional arguments on start.
  • Disables autoscaling
  • Ability to target specific instances through unique hostnames (1.db, 2.db, 3.db).
  • Automatically prioritizes stateful instances for system resources.

Provide additional commands on start

As application complexity grows you may want to perform complex commands on start. For example, running a complex set of flags when you start a database.

With stateful instances on Cycle, you can add extra command line arguments or replace the image default command for targeted instances. (i.e. specifying one of three database instances to act as a ‘primary’ on startup).

Disables Autoscaling

Cycle takes the approach that stateful containers should not be auto-scaled by the platform. Since stateful applications typically require extra processes and rules to determine when to scale, Cycle leaves that responsibility up to users through the use of orchestrators.

Resource Prioritization

If a box starts to reach resource capacity, CycleOS will kill off stateless containers prior to stateful containers.


A stateless instance is like cattle. No individual in the herd is irreplaceable to a farmer. Each member has the same value and can be replaced as easily as it was lost.

The goal of this architecture is to have an application that can be started, stopped, deleted, remade, distributed, and run again all with minimal difference in user experience.

Use Cases

  • Static Webpages
  • APIs
  • Data Processing
  • Rendering

Stateless on Cycle

  • Volumes are reset every time the container is initialized.
  • Containers are given lower priority to system resources versus stateful containers.
  • All instances are treated equally and share the same base hostname.


It’s undeniable that every application is different. The industry-wide move to containers has brought with it new considerations when creating your application architecture. Each container, in itself, is infrastructure… fully customizable and as disposable or precious as you see fit.

Still Have Questions?

If you want to dive in and learn more, head over to our slack channel. Our community is growing, and our team hangs out there daily. Feel free to shoot us a message any time with your questions and we’ll be sure to respond!

Of course, for a more in-depth look at how to use Cycle, check out our documentation.