What are Stacks, Stages, and Environments?

In the DevOps world, we sometimes struggle with terminology. In this post, I'll dive into three terms that we use often but sometimes define loosely: stacks, stages, and environments.

If you're new to the concepts of Continuous Integration pipelines, stacks, and stages, check out my discussion on stacks and stages on AWS first.

Environments

Let's start with environments. In our view, an environment is a runtime for an application, complete with all of its code, components, and configurations.

The term "environment" has been around for a while. It crops up in expressions like "environment variables" and "runtime environment". The key point is that an environment can be located anywhere. A production environment, for example, can exist in a data center or the cloud. A developer can stand up a dev environment on their own laptop or desktop. A QA engineer or DevOps engineer may stand up a test environment in a set of servers in the company closet.

Stacks

A stack is your application plus everything that it requires to run. This can include (but is not limited to) networks, servers, storage folders, Docker containers, build pipelines, etc.

We use the term "stack" particularly in the framework of Infrastructure as Code. In the past, we would commonly assemble environments by hand. This led to instability and mismatches between environments. With Infrastructure as Code, we can deploy a stack automatically as a single unit.

Since a running stack creates an environment, there's a lot of overlap between the two terms. The key difference is that a stack is a deployable unit we can use to stand up a new environment automatically.

Stages

A stage is a stack that you deploy for a specific purpose.

Stages are used in code pipelines to provide an on-ramp to push code changes from smaller to wider audiences. For example, a change will typically start with a dev stage (either a team or a personal dev stack). If the change works on the dev stage, a team may next push it to a test stage where internal stakeholders can access it, followed by a staging stage where it's available to a limited number of external customers. Finally, if the change passes all automated and manual tests, it'll be pushed to the production stage.

Stages can also be referred to as "environments" - for example, the dev environment, test environment, etc.

Ephemeral Environments

A stage can be either long-running or ephemeral. Traditionally, stages have been long-running. But more and more we're seeing a shift to ephemeral environments. Teams may stand up environments quickly to test one or two specific changes. And developers will typically reclaim their environments during non-working hours to trim cloud costs.

Ephemeral environments and pipeline stages are making collaboration easier. Tools like Netlify and Vercel simplify generating preview deployments for application front ends. On the backend, tools like TinyStacks make it easy to spin up (and spin down) preview, demo, and production stages, and to integrate cloud services in new and interesting ways.

TinyStacks Simplifies Pipeline Management

At TinyStacks, we're passionate about enabling regular humans to stand up a full DevOps pipeline with all of the stacks and stages their teams require - without losing visibility or control of native services. Take a peek at our getting started docs and then 12 minutes to deploy a test project and see what your team is missing.