Environments

👍

Key takeaways

• Environments isolate sets of services while sharing the same computing resources underneath.
• Environment names are hostnames.
• The default environment when working in development is dev.lever.
• A special admin environment is used under the hood for controlling Lever itself.

Lever environments are a way to isolate multi-tenancy within a Lever cloud. Multiple Lever customers can use a single Lever cloud in such a way that their services are isolated from one another, even as they all share the underlying computing resources. A typical use case for environments might be separating staging and production or splitting large teams within an organization.

Each Lever environment has a hostname associated with it. For example api.your-website-domain.com or myapp.some-lever-hosting.com. This allows for a universal addressing scheme for invoking Lever methods from any provider. See also Lever URLs. In development, Lever provides the environment dev.lever to work on, as well as the admin.lever environment.

The isolation provided by environments have a number of consequences. The most important one is that services marked as private can only be accessed from within their own environment. See also private property in lever.json.

🚧

Coming soon

Adding and removing environments is not yet possible. This will be possible in a future version of Lever via the Lever CLI.

The admin environment

Each Lever installation has a special environment, called the admin environment, which is used for managing Lever itself. It is used underneath by the Lever CLI for making deployments onto Lever. The reason for implementing the internal management logic as a Lever service itself is that it requires the same features as regular Lever services:

• Auto-scaling with demand.
• Accessible through various interfaces, like Lever RPC and the HTTP API.

When deploying to Lever, you normally need to specify the admin environment (via the --admin flag) and the environment you want to deploy to (via the --env flag). These flags have reasonable defaults such that running lever deploy without these flags, in development, just works. For more details see the lever deploy command.