Helix Core is now P4 and Helix Swarm is now P4 Code Review. Product user interfaces will be updated soon. Learn more >>

Documentation | 2025.5

# Upgrading a Docker container

This section describes how to upgrade a Docker container that is running P4 Code Review to a newer release.

The following process attempts to minimize downtime, but a short period of downtime for P4 Code Review users is unavoidable. There should be no downtime for your P4 Server. After a successful upgrade, all P4 Code Review users are logged out.

If you are using P4 Code Review in a production environment, we encourage you to test this upgrade process in a non-production environment first.

To upgrade a Docker container, run the following commands in your Docker setup directory:

1. Pull down the latest version of the P4 Code Review image. In the below code example, you can change the latest tag to the current version of your P4 Code Review installation, for example, 2022.2.

       docker pull perforce/helix-swarm:latest

2. View what is currently running in your Docker container using docker ps command.

       docker ps
       CONTAINER ID   IMAGE                  COMMAND                  CREATED          STATUS          PORTS
       NAMES
       0b3baaf10387   perforce/helix-swarm   "/bin/sh -c /opt/per…"   22 seconds ago   Up 20 seconds   0.0.0.0:80->80/tcp,
       :::80->80/tcp
       helix-swarm
       f2030d449679   redis                  "docker-entrypoint.s…"   38 seconds ago   Up 37 seconds   6379/tcp helix-redis

3. Stop and delete the running P4 Code Review image.

       docker stop helix-swarm
       docker rm helix-swarm

4. Start a new P4 Code Review image using a docker run command. For more information on how to run a P4 Code Review image on a Docker container, see Run P4 Code Review using a Docker container.

## Secure your P4 Code Review installation

To make your P4 Code Review installation more secure apply the following recommendations for HTTP and P4 Code Review implementation through security groups.

### HTTP

Here is a list of best practices to use when port 80 is exposed for HTTP traffic:

- Redirect to HTTPS: If Port 80 needs to be open to support legacy systems or specific use cases, ensure that all HTTP traffic is redirected to HTTPS to encrypt data in transit.

- Use HSTS (HTTP Strict Transport Security) headers: Implement HSTS headers to force browsers only to use secure HTTPS connections when interacting with your server.

- Close port 80: If there is no requirement to use HTTP, Port 80 must be closed entirely to prevent any unencrypted data transmission.

- Implement SSL/TLS (secure sockets layer and transport layer security) certificates: Ensure that your server is configured with a valid SSL/TLS certificate to enable secure HTTPS connections.

- Firewall configuration: Configure firewalls to block or filter access to Port 80, particularly from untrusted networks.

- Continuous monitoring and auditing: Regularly monitor network traffic and audit server configurations to ensure that unnecessary ports are not exposed and that data is transmitted securely.

When you implement HTTPS, you must make the following changes:

1. Modify your cron job for the P4 Code Review workers.

   Edit the cron configuration file to point to your HTTPS URL, for example, https://HOSTNAME/. For more information about how to edit the cron configuration file, see Set up a recurring task to spawn workers.

   To verify if the cron configuration file points to your HTTPS URL, run the following curl statement:

   curl https://myswarm.host/queue/worker

2. Modify the P4 Code Review Extension or Trigger configuration with the following:

   1. If you are using the P4 Code Review extension run the following command and change ExtConfig’s P4 Code Review URL to be your new HTTPS URL:

      p4 extension --configure Perforce:helix-swarm

   2. In the ExtConfig block, find SSL-CA-File and set the absolute path of the Certificate Authority (CA) Privacy-Enhanced Mail (PEM) file to validate the P4 Server's certificate for P4 Code Review. Ensure that this file is accessible to the P4 Server process owner. By default, the local certificate stored in the default CA file is used if the absolute path for the Certificate Authority (CA) is not specified.

      If a suitable certificate is not found in the local SSL certificate store maintained by the operating system or if there are verification issues from using a self-signed certificate then the default CA file is used.

   If you are using triggers, edit swarm-trigger.pl configuration file and set your SWARM_HOST to be https.

3. Edit the external_url in the `SWARM_ROOT/data/config.php` file’s environment block to point to your HTTPS URL. This URL is used in emails, Jira links, and P4 Code Review test’s pass-and-fail outgoing URL parameters.

   If you make a configuration change, P4 Code Review will not use it until the configuration cache has been reloaded, this forces P4 Code Review to use the new configuration.

   You must be an admin or super user to reload the P4 Code Review config cache. Navigate to the User id dropdown menu, select System Information, click the Cache Info tab, and click the Reload Configuration button.

4. Modify the P4 Server's P4.Swarm.URL property. For more information about P4 Server integration, see Client integration.

   If your Apache server is listening on both HTTPS and HTTP in perforce-swarm-site.conf file, you must set the auto_register_urlconfigurable in the p4 block to false and correctly configure the P4.Swarm.URL property .

   If your Apache server is listening only on HTTPS and if the auto_register_urlconfigurable in the p4 block is set to true (default value), an Apache restart will correct the property.

   To get all your current values for P4.Swarm.URL property, run:

   p4 -Ztag property -A -l -n P4.Swarm.URL

   Ensure that the P4.Swarm.URL property points to your HTTPS URL.

5. Modify the URL of all applications. Any other applications that reference the URL should be switched to using the HTTPS URL.

### P4 Code Review implementation through security groups

You can implement security headers by using security groups or the user's preferred setup.

Review the following guidelines:

- Use a trusted proxy: Use a trusted proxy, such as allow lists, Content Delivery Networks (CDN), or API Gateways.

- Disable backend servers and other proxies or load balancers: Ensure that direct access to backend servers and other proxies or load balancers is disabled, except through the trusted proxy. In this way, you can help to prevent unauthorized access while ensuring that all requests are filtered through the trusted proxy.

- Implement continuous monitoring and logging of the X-Forwarded-For header: Implement monitoring and logging on the X-Forwarded-For header to track and identify any suspicious activities. Continuous monitoring can help to identify and prevent potential malicious activity or security threats.

- Use a secure protocol: Implement a secure protocol such as HTTPS to encrypt the communications between the client and the load balancers, and between the load balancer and backend server to prevent eavesdropping or tampering with the X-Forwarded-For header.

- Configure the X-Forwarded-For header: Configure the processing mode of the X-Forwarded-For header (append, preserve, or remove) based on specific technical or security requirements.

Your search for returned results