You're viewing **Apigee Edge** documentation.  
[Go to the
**Apigee X** documentation](http://cloud.google.com/apigee/docs/api-platform/deploy/ui-deploy-overview). info

This topic provides a quick overview of proxy deployment. You can deploy proxies using the
management UI, command-line scripts, or with APIs.

**Video:** Watch a short video to learn about best practices for zero down-time
during API proxy deployment.
[Video](https://www.youtube.com/watch?v=Hgr6PtZpqIg)

## When to deploy a proxy

A proxy must be deployed before it can be invoked. Generally, it's up to you when you deploy.
When you are working in a test environment, you may deploy iteratively many times. On the other
hand, the decision to deploy a proxy from the test environment to a production environment
usually depends on lifecycle rules established by your development team.

Deploy or redeploy a proxy when you:

- Create a new proxy (deployment happens automatically)
- Modify an existing proxy
- Create a new revision of a proxy
- Create a new version of a proxy
- Push a proxy from one environment to another, such as from a test environment to a production environment.
- Delete and recreate a [keystore](https://docs.apigee.com/api-platform/system-administration/configuring-ssl-edge-backend-service).

## Where to deploy a proxy

You deploy a proxy to an *environment* . All organizations in Apigee Edge, by default,
have two environments called *test* and *prod* . These environments are merely
designed to provide you with one area to work on and test API changes, and another area where
APIs are exposed to apps. The following figure shows a proxy that is deployed to the
`test` environment, as indicated by the green dot.

![](https://docs.apigee.com/static/api-platform/images/proxy_deployed.png)

> [!NOTE]
> **NOTE:** Depending on your role, you may not be able to deploy to all environments. Users can only deploy to the `test` environment. If you're an administrator you can deploy to any environment.

## How to deploy a proxy

How you deploy a proxy depends on where you are developing the proxy. If you are working in
the UI, you can easily deploy a proxy with just a couple of mouse clicks. A new proxy is
automatically deployed when you create it; you don't have to do anything special. The
procedure for redeploying an existing proxy is almost as simple. Just select which deployment
environment to deploy to, and the management UI takes care of the rest. For more information, see
[Deploying proxies in the UI](https://docs.apigee.com/api-platform/deploy/deploying-proxies-ui).

If you are developing proxies and related components offline (that is, working with proxy XML
files and other code directly on your filesystem), Apigee Edge provides a convenient command-line
deployment tool that you can use. You can also obtain a sample shell script that you can
configure and run to upload and deploy your proxy files. For more information, see [Deploying proxies from the command
line](https://docs.apigee.com/api-platform/deploy/deploying-proxies-command-line).

Finally, you can use the Edge management API to deploy proxies. The deployment APIs expose
atomic functions that your development team can coordinate to automate and optimize your API
development lifecycle. See [Deploy API proxies using the
management API](https://docs.apigee.com/api-platform/deploy/deploy-api-proxies-using-management-api).

## What is an API Proxy Revision?

Revisions let you manage API proxy updates as you create and deploy them to an
environment. Revisions are sequentially numbered, enabling you to revert a change by
deploying a previous revision of your API proxy.


Only one revision of an API proxy can be
deployed in an environment at a given time if revisions share the same API proxy base path.

> [!WARNING]
> **Deploying multiple revisions of a proxy to the same environment**   
> It is currently possible to deploy multiple revisions of an API proxy in the same environment if they have different base paths. However, this capability is deprecated. In the future, deploying revisions of the same proxy to the same environment concurrently will be forbidden. At that time, any new deployment will replace the older deployment.

Typically, an existing revision must be undeployed before a new one can be deployed. Other
advanced options include overwriting a deployed revision or opting not to increment a revision at
all. For example, sometimes when you make minor changes, you might not want to increment the
revision. These advanced options can be accomplished through direct calls to the Edge
management API. See [Deploy API proxies using the
management API](https://docs.apigee.com/api-platform/deploy/deploy-api-proxies-using-management-api).

You can deploy a revision of an API proxy into the `prod` environment, while
continuing to create new revisions of that API proxy in the `test` environment. When
you are ready, you can "promote" the higher revision of your API proxy from the `test`
environment over the prior revision of the API proxy in the `prod` environment.

For more information on revisions, see [Deploy API proxies using the
management API](https://docs.apigee.com/api-platform/deploy/deploy-api-proxies-using-management-api) and [Deploying proxies
in the UI](https://docs.apigee.com/api-platform/deploy/deploying-proxies-ui).

**Video:** Watch a short video to learn more about API revisions.
[Video](https://www.youtube.com/watch?v=V0RuFJdHN-o)