Your production environment(s)

You’ll probably have a dev environment and at least one production(-like) environment. Spynl helps you to:

  • keep the code consistent between deploys to each of them
  • Make sure test do not affect real users and unfinished things are turned off in production
  • allow a third party to control your prodcution pipeline


We use Docker to ship Spynl. You can be sure there that you look at the same code in dev and production. (/about/versions can help you to look up precisely which code is in there).

/about/build helps you to see when the Image was made (built on Jenkins) and when it was started.

The image is Ubuntu-based.

Custom pre-install and post-install hooks are possible in (also works for dev.install) can influence production.ini or other relevant things in the Docker container right before it is run.

Possibilities to turn off endpoints and whole resources on production

(TODO: add issue about a more generic approach)

Do not send emails to real addresses from non-production environments

TODO: link to the email section

Using different container registries for dev and for production

Useful if you keeo them separated or a thrid party manages your production pipeline (e.g. when using a DTAP approach).