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.
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?
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.
.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. 😅
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:
It’s time to retire your
.env files in favor of a workflow that addresses these issues.
Let us show you a better approach.
As a marketplace for developer services, Manifold gives you and your team the tools they need to effectively manage and distribute 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).
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.
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.
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.