viewing Apigee X documentation.
View Apigee Edge documentation.
This section describes environments and environment groups.
An Apigee environment is a software environment, within an organization, for creating and deploying API proxies. You must deploy an API proxy to an environment before it can be accessed. You can deploy an API proxy to a single environment or to multiple environments.
Each environment is limited to 60 total deployments, at most 50 of which can be proxy deployments.
An environment group (sometimes called an envgroup in the Apigee API) is the basic mechanism for defining the way requests are routed to individual environments. You define hostnames on your environment groups (not on individual environments), and Apigee routes requests to the environments within a group using those hostname definitions.
An environment must be a member of at least one environment group before you can access resources defined within it. In other words, you must assign an environment to a group before you can use it.
The logical grouping of environments by environment group provides the following benefits:
- Centralized hostname management: Environment groups provide a centralized place to manage hostnames.
- Aggregate insights: With groups, you can analyze errors by looking at reports for an entire environment group at once rather than individual environments.
- Conflict avoidance: By grouping environments, you can ensure that the base paths for your environments don't exist under the same hostname.
Supported deployment types
Apigee supports the following deployment types in an environment:
|Proxy||Develop and test your API proxies in your Apigee development environments, and then deploy them to Apigee integration test and production environments. See Deploying an API proxy.|
|Archive||Develop and test your programmable API proxies using Apigee in VS Code or your configurable API proxies manually. Then, deploy an archive of your API proxy configuration environment to your Apigee integration test and production environment. See Deploying and managing archives in an Apigee environment.|
Summary of prevented actions with archive deployment
When you enable archive deployment in an Apigee environment, you will be prevented from performing the following actions within the environment to prevent conflicts:
- In the Apigee UI, you cannot view, confirm deployment status, or manage your archive deployments, as described Deploying an API proxy, or use the Debug UI as described in Using Debug. As a workaround, you can use gcloud or the API to List all archive deployments in an environment and use the Debug API.
- You cannot create, update, or delete resource files or target servers using the Apigee UI, API, or gcloud.
- At this time, Google Authentication using Service Accounts is not supported.
If you attempt to perform any of the prevented actions listed above, the action will fail with the following error message:
The following table lists important points to remember about environments, organizations, and environment groups:
The following sections show common ways in which environments are structured within environment groups.
One environment group and one environment
The simplest structure is a single environment group with a single environment in it. This is common for organizations that are currently evaluating the product or have not yet set up testing or analytics infrastructure, nor have any proxies deployed in production.
Multiple environments in a single group
An organization can contain multiple environment groups. For example, you might define the
prod environment groups in an organization, and map each of those to a single
hostname (or IP address). Within each group, there might be one or more environments:
Environment groups aligned with access
Because you can assign the same environment to more than one group, you can organize your environments by access. For example, you can make your production environments accessible on a single internal environment group, but limit access to some of those environments on a public group, which would be open to the internet:
Environment groups aligned with business units
With a larger, more mature set of actively deployed proxies, it is common to align environment groups with business units. For example, you might have environment groups for your testing, production, and development teams:
Ready to create a group?
To learn more about environments:
To learn more about environment groups:
Routing and base paths
In a simple configuration, a request to a deployed API proxy is made up of a hostname, base path, and the name of an API resource; for example:
https://www.example.com/shopping/cart/addItem |_____________| |___________| |_____| | | | hostname basepath resource
You define hostnames on the environment group so that multiple environments can share them. Basepaths and API resources are defined on the API proxy.
For more information about base paths and API resources, start with Understanding routes. In addition, check out the Flow configuration reference and Flow variables reference to gain a greater understanding of how these pieces fit together.
When you create an environment group, you attach one or more hostnames to that group. For example, you might have the following environment groups, each with its own hostnames:
|Environment Group Name
You define base paths on the proxy when you create it.
When you deploy a proxy to an environment within the group, the hostname plus the base path and the resource name together define the endpoint of an API request to that proxy.
You can define more than one hostname on an environment group. They can all be used to call any
proxy deployed to any environment in the group. For example,
payment.example.com/proxy1 will both call the
proxy1 resource if
payment.example.com are defined on
the same environment group.
To support multiple hostnames on a single environment group that is shared by multiple environments, Apigee routes API requests to different proxies in different ways.
prod-groupenvironment group contains the following environments:
prod-grouphas the following hostnames defined on it:
The following proxies are deployed to these environments:
catalog-prodwith a base path of
cart-prodwith a base path of
pymnt-prodwith a base path of
This creates the following endpoints:
catalog.example.com/catalogroutes to the
catalogproxy in the
catalog.example.com/catalog/cartroutes to the
cartproxy in the
payment.example.com/paymentroutes to the
paymentproxy in the
The following example shows that the requests are routed to different proxies that are deployed to environments within the group, depending on the hostname and the base path:
Shared environments and routing
An environment can belong to multiple environment groups. If you deploy a proxy to such an environment, the proxy will have a multiple addresses, one for each environment group the environment belongs to. This is useful if a customer has wildcard certificates (like *.example.com) for multiple partners.
shared-envbelongs to two environment groups:
partner-1with host alias
partner-2with host alias
foois deployed to
shared-envwith a base path
shared-envis shared by both environment groups,
foohas two addresses:
Note that both of the hostnames route to the same environment. This gives each environment group a unique domain name. For Apigee hybrid, this scenario can use mTLS with a different certificate for each partner.
About environment scope
The organization provides scope for some Apigee capabilities. For example, key-value-map (KVM) data can be made available at the organization level, meaning that API proxies deployed to any environment within that organization can access the same KVM data.
Similarly, some capabilities can be scoped to environments or environment groups within the organization. For example, Apigee analytics data is partitioned by a combination of organization, environment, and (eventually) environment group.
Every deployment to an environment has the potential to affect the routing of traffic for every environment group to which that environment is attached. When new basepaths are added, they may start capturing entirely new traffic, or they may start capturing a subset of existing traffic already being handled by an existing deployment.
Similarly, when basepaths are removed, they may correspond to endpoints that no longer receive any traffic, or they may cause existing traffic to be rerouted to a different proxy. When traffic is rerouted, it may be to some proxy in the same environment, or when multiple environments share a single environment group, it may be to a proxy in a different environment.
The following information describes how to manage your environments and environment groups:
With the Apigee UI:
With the Apigee API: