Upgrading from Trial to Full Version#
When upgrading from the trial version to the full version of Apidog, all application data is retained without the need for data migration or reconfiguration. For on-premises deployments, the upgrade process is straightforward, simply replace the trial license with the full-version license by updating the LICENSE environment variable in your deployment configuration.1.
Ensure that the deployment environment is properly prepared to handle the new license.
2.
Update the LICENSE environment variable in your deployment configuration to reflect the full-version license key.
3.
Restart the application to apply the new license.
Renewing Your License#
Renewing your Apidog license does not affect the application’s data or configuration. No additional data migration steps are required. To ensure uninterrupted access to Apidog in an on-premises deployment, it is essential to update the LICENSE environment variable in your deployment configuration before the license expiration date.If your current license is nearing expiration or has already expired, follow the steps below:1.
Stop and remove the running apidog container:
2.
Refer to the Installation Guide, update the LICENSE environment variable in your deployment environment to reflect the new license. After updating the license, restart the Apidog container to apply the new configuration. Do not change the JWT_SECRET environment variable, as modifying this will impact user authentication and sign-in functionality. This variable should remain unchanged to ensure that existing user sessions and authentication tokens remain valid.
Zero-Downtime Deployment#
Zero-downtime deployment is critical in production environments. To ensure continuous availability during version updates or configuration changes. Apidog supports both Docker and Kubernetes deployments with strategies that minimize downtime.Adjust the upstream backend for the containers to ensure traffic is routed to healthy instances during updates.
Gradually replace old containers with new ones to ensure no service interruptions.
In Kubernetes, a rolling update strategy can be implemented using the Helm chart configuration or by modifying the deployment manifest. To configure this:Modify the Deployment manifest or Helm chart values to include the following rolling update strategy: strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 1
maxUnavailable: 0
maxSurge: Defines the maximum number of pods that can be scheduled above the desired count during an update. A value of 1 ensures that only one additional pod will be started at a time.
maxUnavailable: Specifies the maximum number of pods that can be unavailable during the update. Setting this to 0 ensures that no pods will be taken down during the update, guaranteeing high availability.
Apply the updated deployment configuration to your cluster.
