As a marketplace for developer services, Manifold gives you and your team the tools they need to effectively manage and distribute configuration. Here we'll establish a common definition for configuration, illustrate why old methods don't scale and show you how we help your apps be cloud native.

What is configuration?

Applications depend on external services and context to operate. Your database doesn’t run on localhost, transactional email is handled by a service like Mailgun, and your application behaves differently depending on which environment it’s running (local, staging, production).

We represent these dependencies as configuration in simple key, value pairs.


Traditionally, making this config available to a running process boiled down to hard-coding and importing values in a .env file, which we’d explicitly ignored in our .gitignore (so it wasn’t accidentally committed).

In a small, simple application the .env approach works, but does it scale as your application grows in size and complexity?

Story Content

Why configuration management?

Fast-forward a year— congratulations, your user-base has grown 10x. 🎉

How has our code-base and architecture changed as a result?

Once upon a time, the only thing growing faster than our user-base would be the size and complexity of our repo. When latency became an issue, we’d just upgrade the hardware our monolith was running on.

Our .env file was longer, but at least we still only had to manage a handful of them.

Today, we build applications native to the cloud. When we need to support more traffic, we scale horizontally by creating more instances of our application. When we need to introduce new functionality, we add new services—we build what we have to, and buy everything else.

The catch? Each service is small, self-contained and simple, some of them are even managed for us, but wow—we have lots of them. 😅

Story Content

Now, it’s the size and complexity of our configuration that’s growing in relation to our application. How’s the old .env approach holding up? Not great, here’s why:

  • We manage too many services to roll every .env configuration file by hand.
  • Each environment has its own mechanism for consuming configuration.
  • Every member of our team will require a local version of this configuration.
  • Every service we add or remove will result in cascading changes to configuration.
  • The contents of configuration will include secrets (identity database, etc) that must only be accessible to specific people and environments.

It’s time to retire your .env files in favor of a workflow that addresses these issues.

Let us show you a better approach.

Manage your config with Manifold

As a marketplace for developer services, Manifold gives you and your team the tools they need to effectively manage and distribute configuration:

Story Content

Organize your services and configuration

Purchase your managed services in the Manifold Marketplace and then compliment them by adding additional configuration and secrets, creating a single source of truth for your team which makes it easier to integrate with your application.

Example: Start by creating a project for your new API, provision a JawsDB Postgres database, and use a custom resource to define your application config (such as session keys, endpoint configuration or feature flags).

Add your other managed service config

When adding your own configuration to a Manifold project you can select a service template. Service templates reduce the headache of importing secrets from your favorite managed services. Choose the service you would like to manage the configuration for, and we pre-populate a custom resource with the fields you need.

Integrate with any platform

We integrate directly with your existing workflow and deployment pipeline. Simply define which project you want to source configuration and secrets for, and we deliver it to any platform using one of our integrations. No more .env files on disk.

Example: In development you can use the Manifold CLI to run your application. It will automatically expose your configuration as environment variables, streamlining the process of onboarding a new developer.

Better access controls

Your projects are segmented into Teams which enable you to control who has access to which services and configuration. Use roles to determine which level of access each team member is granted.

Example: Create a token for your CI/CD platform with only Read Credentials access. When executing your test suite, it only needs access to the values and should not modify resources.

Import a service, manage your config

Manage your configuration with Manifold by checking out our documentation, or select a service to import from our homepage.

Manifold Background

Managing Configuration with Manifold

Manifold gives you and your team the tools they need to effectively manage and distribute configuration.
twitterShare Story