Deploying Orbital

Managing secrets

Generally, when defining either connections or authentication tokens you need to store sensitive values.

As Orbital is built around file-based and git-based data stores, these are values you generally don’t want checked in.

Environment variables

All Orbital config files are defined in HOCON format, which allows for variable substitution from the environment.

When deploying Orbital into production, it’s recommended to keep secrets in a secret store (eg., Vault), and inject them into the environment as part of the machine provisioning process.

Orbital will correctly inject these values into placeholders.

Using env.conf for sensitive data

In addition to the standard HOCON rules for resolving variables, Orbital supports the use of a env.conf file as a source for substitutions.

This can be useful when developing locally, to ensure that sensitive values aren’t accidentally checked in, but to avoid having to configure environment variables, which can be fiddly.

The general workflow is as follows:

  • Define a connections.conf file with your connections, using ${variables} for placeholders of sensistive data.
  • Create a local env.conf file.
  • The location of the env.conf file must be along side the connections.conf file - ie., the path defined in your taxi.conf file
  • Populate the env.conf file with sensitive values.


jdbc {
  my-connection {
    // ... other params omitted for brevity ...
    connectionParams {
      password = ${postgres_password} // Reads the environment variable "postgres_password"
Configuring Orbital
Authentication to Orbital