Setup Your Production Environment

Setting up Production

Similar to when you setup your initial environments on Coherence, you'll need to give our managed service account a role in your production account (AWS) or project (GCP). You set up this link using the flow on the Collections tab of your dashboard. See more about Collections here.

Production Databases

One important distinction between pre-production environments, like the ones in your review account, and production ones, is that you might care a lot more about the data. At the very minimum, we want to note that:

  • Coherence does not enable backups or high-availability for your database by default.
  • We also do not provision a large instance - the default is a micro with 10GB of storage.
  • You can modify these settings on the instance we will create directly in the cloud console or with the CLI. If you prefer to use a database instance that you manage yourself, we support that as well.

You can use the web cloud console for AWS/GCP, or CLI tools (e.g. aws cli or gcloud cli) to change the backup, availabailty, instance size, maintainence window, replication settings, storage size/class, and other settings of your production database after it is created by Coherence. Deletion protection will be enabled by default. Changing the provided Configuring instance size/backup settings will NOT require any change to your coherence.yml and Coherence will not treat it as drift when we update your environments as you add other resources and deploy new code.

Using a self-managed database instance

When you configure a database resource in your yml, Coherence is reponsible for creating the instance, adding logical databases onto it, managing the users that have access (and their passwords) and for deleting the instance and databases when the environment is torn down. If you prefer to manage all these operations yourself, you can create your own database instance in production and configure Coherence to use that instance for your application.

To use a self-managed instance, you'll need to:

  • finish the production cloud role integration, after which we will setup your initial environment
  • update your yml to indicate the configuration information for the existing instance (see the database resource docs for yml examples)
  • delete the instance we create for you in the CLI or web console, since we enable deletion protection by default. Otherwise, you'll see an error message the next time you promote to production after updating your yml to use an existing instance.

Please see the section on Production Databases above before considering the use_existing option. Feel free to ask us if this option makes sense in your case, it's not required in all cases.

For AWS:

  • You'll need to wait until we deploy the initial infrastructure to this project (after you finish the production setup flow), and then you can create an instance in the VPC we deploy. You can choose a highly-available cluster or an Aurora cluster in addition to a standard RDS instance. See the notes on configuring existing databases if you choose to go this route.

For GCP:

  • The instance can exist before we create the VPC, but it needs to be in the same project you've added our role to in the production setup flow.

Production IAM Role


You can use a more tightly-scoped role than AdministratorAccess for Coherence's production access to your AWS account, if you'd like. Here's an example:

    "Version": "2012-10-17",
    "Statement": [
            "Sid": "",
            "Effect": "Allow",
            "Action": [
            "Resource": "*"