A stack is composed by a stack part and a config part (see Concept of a stack).

Our app is designed to easily mange the stacks content and configuration files through the Catalog Repository and Config Repository pages, with only need of providing SSH credentials and repository URLs.

# Designing a Stack

As explained above stacks concept is a way to organize Infrastructure as code files. Additionally to this concept, it is important to take time to define what should we put in a stack.

The main recurrent interrogation from our customer is "how could I put my current application in a stack?"

To this question, there is no unique answer. The stack concept is really flexible and it will be up to the creator of the stack to define what it contains.

The 3 major points which lead how to design a stack are:

  • Goal of the stack: Which service or application do we want to pack? And who will be the user of the stack?
  • Application dependencies: What are the dependencies of my application from an infrastructure and deployment point of view.
  • Security/political restriction: Are there any specific security rules or teams responsible for some resources.

Then the design of a stack could impact it's

  • Reutilisability: If the stack is too specific it could be hard to reuse it in other projects.
  • Maintenance and complexity: More the stack contains resources and use-cases, the harder it will be to maintain and update the infrastructure as code.

Keeping the previous points in mind, let's now see two concrete examples of application and how could it be defined as stacks. In addition, you can also read a bit more about Terraform recommended patterns (opens new window).

# Web application example

Here is a simple web application composed of compute instances on top of a network VPC.


One approach would be to create an entire standalone stack. This stack will contain all resources to compose our application. Using infrastructure as code we will describe VPC network and compute instances.


This way each user of the stack would be able to deploy a fully standalone web application. The stack will create for each user a dedicated VPC network and spawn the compute instances on top of it.

Now let's take a second approach and split this stack into two different ones. One dedicated to the network and one dedicated to instances.


This way your application is not anymore standalone but allows users to create a shared network using the network stack. And deploy several instances using the instance stack on this shared network.

Using the stack concept in Cycloid you will be able to link stacks together and let your users select the network previously created by the network when they will deploy their application using the instance stack.

In the case of shared responsibility across teams, the network team could create a network project on the Cycloid dashboard based on the network stack. And the developer could deploy their applications with the instance stack using the network created by the network project. And access to project limited using Cycloid role and policies management.


This approach could also be used and applied to any other components like Object storages, Databases, etc.

# Kubernetes example

At Cycloid we highly use and deploy containerized applications in Kubernetes. let's see how we do it using stacks.

If we simplify our workflow around Kubernetes, it could be seen as two use-cases:

  • Create and manage the Kubernetes cluster
  • Build container applications from application source code and deploy it on a Kubernetes cluster


To solve our needs we split them into two defined stacks:

  • One to handle the infrastructure part: the creation of a Kubernetes cluster, access management, etc.
  • And another one to define the entire application workflow: starting from the source code, going through our build process, and finally to the deployment on a Kubernetes cluster.


On the Cycloid dashboard, we created a Kubernetes project based on our infrastructure stack and an application based on our application stack. This splitting method provides a way to manage our Kubernetes cluster and deploy as many applications as we want on top of it.


All this work can be found as part of our public stacks. We provide different infrastructure stacks to create a Kubernetes cluster on different cloud providers:

Our application stack to build and deploy containers on Kubernetes cluster can also be found in our public stack called k8s-runner (opens new window)