API Deployment Types

Portal Admins and API Owners can control how APIs are deployed to a proxy using the API deployment type. You select the API deployment type when adding proxies.
For more information about how to add a proxy, see Integrate On-Premise API Proxies.
The API Details page displays the API deployment information on the
Deployments
tab. The following graphic displays the Details page of API deployment information for different API deployment types and proxies:
Proxies support the following API deployment types:
  • Automatic
    For this API deployment type,
    Layer7 API Developer Portal
    immediately and automatically deploys changes to the published APIs to all proxies. For example, whenever an API is added, edited, or deleted. This is the default type.
  • On Demand
    For this event-driven API deployment, users with deployment permissions can deploy the API to the proxy as needed. The Portal Deployer client handles te deployment, undeployment, and redeployment of the API to the proxy. For example, this API deployment type is useful when you want to stagger the deployment of an API across all or your geographic regions to avoid impacting production instances during peak hours.
    To use this API deployment type, you must install and enable the Portal Deployer modular assertion on the proxy during the enrollment or upgrade process.
  • Scripted
    For this API deployment type, you can integrate the API deployment into your CI/DC process by leveraging the Deployment API and invoking them from a custom API deployment script. The deployment APIs retrieve API deployment data and update the API deployment status for a proxy to keep
    Layer7 API Developer Portal
    updated.
    To use this API deployment type, you must install and enable the Portal Deployer modular assertion on the proxy during the enrollment or upgrade process.
On Demand and scripted deployments are available only for Portal-published APIs.
The following table displays more information about API deployment types:
API Deployment Type
Effect on API Deployments
Use Case
Execution Method Used
Note
Automatic
Changes to APIs are automatically deployed to the proxy. For example, whenever an API is created, edited, or deleted.
Backwards compatibility for retaining current deployment model and Gateway-published APIs.
The Automatic API deployment type is recommended for the following use cases:
  • Rapid iteration of API development.
  • Convenience and low maintenance.
  • Development environments.
UI and API call.
The API count displays for the Portal and the proxy on the API Proxy Details page because the APIs are automatically deployed to the proxy.
If you do not use the Automatic API deployment type for a proxy, the APIs are not synched to and from that proxy regardless of where they were created.
Gateway-published APIs
must
use the Automatic API deployment type because they rely on the synchronized scheduled task to synchronize them from the proxy to the Portal.
To enable automatic deployment of Gateway-published APIs, you must enable migration between environments or clusters using Gateway Migration Utility (GMU). For more information, see the following links:
On Demand
You can trigger API deployments on-demand by calling the Deployment API.
Deployments are triggered when a user with deployment permissions makes calls to the Apideployments resource in the Portal API (PAPI).
On-demand deployments apply only to Portal-published APIs.
The On Demand API deployment type is recommended for the following use cases:
  • Deployments that are triggered as needed.
  • Geographically distributed environments.
  • UAT environments.
For example, you want to stagger the deployment of an API across all or your geographic regions to avoid impacting production instances during peak hours.
UI and API call.
Deployment APIs to orchestrate and trigger the deployment process.
The API Proxy Details page displays only the APIs that have been created on the Portal and not the APIs that have been deployed to a proxy.
Scripted
You can integrate API deployments into your existing Continuous Integration/Continuous Deployment (CI/CD) process by using the deployment APIs and invoking them from your deployment script.
Deployments are triggered by the script in conjunction with the deployment APIs which are used to retrieve the API deployment data and update the API deployment status for a proxy.
Scripted deployments apply only to Portal-published APIs.
The scripted API deployment type is recommended for the following use cases:
  • Integrations with existing CI/CD pipeline.
  • Environments that are tightly controlled.
  • Production environments.
For example, you want control over when an API is deployed using a custom script in conjunction with the Deployment APIs.
UI and API call.
Restman used to deploy to proxy.
Deployment APIs and custom script to orchestrate and trigger the deployment process.
API Proxy Details page displays only the APIs that have been created on the Portal and not the APIs that have been deployed to a proxy.