Preprod Environment for Spinnaker

The information below was written for a previous version of Armory Spinnaker (v1.13 and earlier). Please look here for documentation on the latest version.

What To Expect

This guide should include:

Why Do I Need A Preprod Environment?

Spinnaker is still actively being developed by a community of over 50 engineers across many different large organizations and changes are happening rapidly. This introduces a level of risk that can be reduced by creating a preprod environment coupled with a suite of integration pipelines that exercise the base functionality of Spinnaker. Additionally, everyone’s cloud environment is unique. Permissions, networking, authentication, baking, and cloud targets differ wildly from environment to environment. This will help add confidence into your deployment practices to practice continuous delivery with Spinnaker itself.

Setting Up A Preprod Environment

When Armory Spinnaker starts, it looks for a property file that matches its stack name. This file should contain key/value pairs that it will use for its environment. It pulls this stack name from an environment file located at: /etc/default/server-env. If you’re using Armory Spinnaker, this file is managed for you by using clouddriver’s global userdata. If a file is found it is appended to default.env and generates a resolved.env for use.

For example, if the stack of your deploy is named preprod, Armory Spinnaker will look for a corresponding environment file named /opt/spinnaker/env/preprod.env and append those values to default.env should one exist.

Notable Environment Properties

For your preprod environment you will want to have it match your production properties as closely as possible with the exception of a few environment properties described below.

S3 Properties

The following determines where Spinnaker will store persistent items like application details, pipelines, etc.
It’s critical that these are not the same as your production deployment.


Redis is used to maintain state of your cloud resources, pipeline executions, authentication sessions and other transient state. For your preprod environment you might want to use a local Redis instead of creating a new one using Elasticache.


Otherwise, if you want to use an external Redis to more closely match your production setup, do the following:

Host Names

You’ll need to create a new ELB for your preprod Spinnaker. These should have the same settings, healthcheck and listeners as your production setup. You’ll likely want to apply friendly DNS records to the given name from AWS. Once they have been configured you’ll need to change the addresses below.


Note: Make sure to remove your DEFAULT_DNS_NAME key from the environment file. Armory Spinnaker will automatically create an internal network for the sub-services to communicate with each other.

Spring Profiles

Spinnaker’s core framework is Spring. Spring uses a hierarchical profile loading system. You can create environment specific properties files that are loaded at runtime. Make sure to leave the armory profiles as the first one in the list, followed by your environment specific profiles. In the example below preprod takes the highest precedence.


Create a new Deploy Stage

Add a new deploy stage to your “Spinnaker Deploy Spinnaker” pipeline. When adding the stage and server group you can use production as the server template. You’ll want to add a manual judgement or integration test stage following the deploy stage so you can confirm that your preprod environment is working as expected. Make sure to change the stack to the name chosen for your environment file, in this example: preprod.

deploy configuration

Your finished pipeline should resemble the following:

preprod environment