An environment provides an isolated context or "sandbox" for running API proxies.
In a single organization, you can create multiple environments. For more information,
see About environments and environment groups.
The following code shows an example overrides configuration where multiple environments are
defined. Note that environments
prod and test have different host aliases:
Suppose a proxy with the base path /foo1 is deployed to environment
test. You could call the proxy like this:
curl -k https://api.example.com/foo1
When this call hits the ingress, the ingress knows to send it to the message processor
associated with the test environment, which handles the request.
Similarly, if foo1 is also deployed to the prod environment,
you could make a proxy
request like this, to the host alias apiprod.mydomain.net:
curl -k https://apiprod.example.com/foo1
And the call is routed by the ingress to the MP associated with that host.
Antipattern: Deploy all of your proxies to one hybrid environment.
Best practice: Create multiple environments and deploy a limited number of proxies
to each one. You can create routing rules that specify which environments
to route specific API proxy basepaths to. For details, see Virtual host configuration.
Limit the number of proxy deployments
For hybrid, the fact that many environments can share the same virtual host means
that you must think carefully about how you manage your proxy deployments to any given
environment. In hybrid, the best practice is to create multiple environments and deploy
a limited number of proxies to each one.
How many proxies should you deploy to an environment? There is not a set answer
to this question; however, the following table provides general guidance on why it's a
good idea to limit the number of proxies deployed to each environment and what you
need to think about when managing proxy deployments:
Issue to consider
Description
Message processor boot-up time
There is a direct correlation between the amount of time a message processor (MP)
takes to boot up and the number of proxies deployed to that MP. In an auto-scaling
Kubernetes environment, an increase in boot time might be a problem. The more proxies
that are deployed to the MP, the longer it will take for that MP to come up if it
needs to be scaled or recreated.
Scaling performance
If you have several proxies deployed to an environment, and one of the proxies gets
a lot of traffic so that it frequently auto-scales, all of the proxies in that
environment will scale with it. The performance effect of scaling multiple
proxies with a single high-traffic proxy might be a problem.
Noisy neighbor
If you have several proxies deployed to the same environment, and one proxy
crashes, then all of the proxies in the environment will be taken down while the
MPs restart. By limiting the number of proxies deployed to an environment, you
minimize the impact of a single proxy crashing.
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2025-08-29 UTC."],[[["\u003cp\u003eThis documentation version (1.2) is end-of-life and users should upgrade to a newer, supported version.\u003c/p\u003e\n"],["\u003cp\u003eEnvironments provide isolated sandboxes for running API proxies, and multiple environments can be created within a single organization.\u003c/p\u003e\n"],["\u003cp\u003eVirtual hosts map routing rules to specific environments, allowing different host aliases to route traffic to different environments like 'test' and 'prod'.\u003c/p\u003e\n"],["\u003cp\u003eBest practice dictates creating multiple environments and deploying a limited number of proxies to each to ensure better performance, scalability, and fault isolation.\u003c/p\u003e\n"],["\u003cp\u003eFactors such as message processor boot-up time, scaling performance, and the "noisy neighbor" effect should be considered when determining the number of proxies to deploy to an environment.\u003c/p\u003e\n"]]],[],null,["# About environments\n\n| You are currently viewing version 1.2 of the Apigee hybrid documentation. **This version is end of life.** You should upgrade to a newer version. For more information, see [Supported versions](/apigee/docs/hybrid/supported-platforms#supported-versions).\n\nAn *environment* provides an isolated context or \"sandbox\" for running API proxies.\nIn a single organization, you can create multiple environments. For more information,\nsee [About environments and environment groups](/apigee/docs/api-platform/fundamentals/environments-overview).\n\n\nThe following code shows an example overrides configuration where multiple environments are\ndefined. Note that environments\n**prod** and **test** have different host aliases: \n\n```actionscript-3\nnamespace: my-namespace\norg: my-organization\n...\nenvs:\n - name: test\n serviceAccountPaths:\n synchronizer: \"your_keypath/synchronizer-manager-service-account.json\n udca: \"your_keypath/analytic-agent-service-account.json\n\n - name: prod\n serviceAccountPaths:\n synchronizer: \"your_keypath/synchronizer-manager-service-account.json\n udca: \"your_keypath/analytic-agent-service-account.json\n...\n```\n- Add a `virtualhosts` property that maps its `routingRules` to the environment(s). \n\n ```\n virtualhosts:\n - name: default\n hostAliases: [\"api.example.com\"]\n sslCertPath: ./certs/fullchain.pem\n sslKeyPath: ./certs/privkey.pem\n routingRules:\n - env: test\n ``` \n\n ```\n virtualhosts:\n - name: external\n hostAliases: [\"apiprod.example.com\"]\n sslCertPath: ./certs/fullchain.pem\n sslKeyPath: ./certs/privkey.pem\n routingRules:\n - env: prod\n ```\n\n\n Suppose a proxy with the base path `/foo1` is deployed to environment\n **test**. You could call the proxy like this: \n\n ```\n curl -k https://api.example.com/foo1\n ```\n\n\n When this call hits the ingress, the ingress knows to send it to the message processor\n associated with the `test` environment, which handles the request.\n\n\n Similarly, if `foo1` is also deployed to the `prod` environment,\n you could make a proxy\n request like this, to the host alias `apiprod.mydomain.net`: \n\n ```\n curl -k https://apiprod.example.com/foo1\n ```\n\n\n And the call is routed by the ingress to the MP associated with that host.\n | **NOTE** On a request to an API proxy, the ingress compares the `Host` header of the incoming request to the list of host aliases to determine which virtual host handles the request. `curl` commands, browsers, and many other utilities automatically set the `Host` header with the domain of the request. If for any reason your app is not setting the `Host` header automatically, you must set it manually.\n\n\n **Antipattern**: Deploy all of your proxies to one hybrid environment.\n\n\n **Best practice** : Create multiple environments and deploy a limited number of proxies\n to each one. You can create routing rules that specify which environments\n to route specific API proxy basepaths to. For details, see [Virtual host configuration](/apigee/docs/hybrid/v1.2/base-path-routing).\n\n Limit the number of proxy deployments\n -------------------------------------\n\n\n For hybrid, the fact that many environments can share the same virtual host means\n that you must think carefully about how you manage your proxy deployments to any given\n environment. In hybrid, the best practice is to create multiple environments and deploy\n a limited number of proxies to each one.\n\n\n **How many proxies should you deploy to an environment?** There is not a set answer\n to this question; however, the following table provides general guidance on why it's a\n good idea to limit the number of proxies deployed to each environment and what you\n need to think about when managing proxy deployments:\n | **NOTE:** When deciding how many proxies to deploy to an environment, be sure to consider the product configuration limits described in [Limits](/apigee/docs/api-platform/reference/limits#hybrid).\n\n Enviroment configuration reference\n ----------------------------------\n\n\n For a complete list of environment configuration elements, see `envs` in the\n [Configuration property reference](/apigee/docs/hybrid/v1.2/config-prop-ref#envs).\n\n Working with environments\n -------------------------\n\n\n For more information about configuration, see the following topics:\n - [Creating new environments](/apigee/docs/hybrid/v1.2/environment-create)\n - [Deleting environments](/apigee/docs/hybrid/v1.2/environment-delete)\n - [Base path routing](/apigee/docs/hybrid/v1.2/base-path-routing)"]]
