{"__v":21,"_id":"572a29d8c2ce542b00e6a8ff","category":{"project":"5723ead0fda3c70e005b88e5","version":"5723eaebeae5090e00ee61f1","_id":"572a28f6d10a200e00b1cb14","__v":0,"sync":{"url":"","isSync":false},"reference":false,"createdAt":"2016-05-04T16:53:10.034Z","from_sync":false,"order":1,"slug":"concepts","title":"Concepts"},"parentDoc":null,"project":"5723ead0fda3c70e005b88e5","user":"5723ea8efda3c70e005b88e3","version":{"__v":3,"_id":"5723eaebeae5090e00ee61f1","project":"5723ead0fda3c70e005b88e5","createdAt":"2016-04-29T23:14:51.190Z","releaseDate":"2016-04-29T23:14:51.190Z","categories":["5723eaebeae5090e00ee61f2","5723f854110e570e00486c7a","572a28f6d10a200e00b1cb14"],"is_deprecated":false,"is_hidden":false,"is_beta":true,"is_stable":true,"codename":"","version_clean":"0.1.0","version":"0.1"},"updates":[],"next":{"pages":[],"description":""},"createdAt":"2016-05-04T16:56:56.115Z","link_external":false,"link_url":"","githubsync":"","sync_unique":"","hidden":false,"api":{"results":{"codes":[]},"settings":"","auth":"required","params":[],"url":""},"isReference":false,"order":2,"body":"[block:callout]\n{\n  \"type\": \"success\",\n  \"title\": \"Key takeaways\",\n  \"body\": \"* Environments isolate sets of services while sharing the same computing resources underneath.\\n* Environment names are hostnames.\\n* The default environment when working in development is `dev.lever`.\\n* A special admin environment is used under the hood for controlling Lever itself.\"\n}\n[/block]\nLever **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.\n\nEach 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](doc:lever-urls). In development, Lever provides the environment `dev.lever` to work on, as well as the `admin.lever` environment.\n\nThe 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](doc:lever-json#section--hash-private-boolean-optional-).\n[block:callout]\n{\n  \"type\": \"warning\",\n  \"title\": \"Coming soon\",\n  \"body\": \"Adding and removing environments is not yet possible. This will be possible in a future version of Lever via the [Lever CLI](doc:cli).\"\n}\n[/block]\n# The admin environment\n\nEach 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:\n\n* Auto-scaling with demand.\n* Accessible through various interfaces, like Lever RPC and the HTTP API.\n\nWhen 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](doc:cli#section--arrow-right-subcommand-lever-deploy-command-options-dir-).","excerpt":"","slug":"environments","type":"basic","title":"Environments"}
[block:callout] { "type": "success", "title": "Key takeaways", "body": "* Environments isolate sets of services while sharing the same computing resources underneath.\n* Environment names are hostnames.\n* The default environment when working in development is `dev.lever`.\n* A special admin environment is used under the hood for controlling Lever itself." } [/block] 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](doc: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](doc:lever-json#section--hash-private-boolean-optional-). [block:callout] { "type": "warning", "title": "Coming soon", "body": "Adding and removing environments is not yet possible. This will be possible in a future version of Lever via the [Lever CLI](doc:cli)." } [/block] # 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](doc:cli#section--arrow-right-subcommand-lever-deploy-command-options-dir-).