It automates the deployment process, so containers are created, configured, and assigned to clients instantly upon purchase.
Clients can control their containers directly from the WHMCS client area, including start, stop, restart actions, viewing logs, accessing the console, and more.
You can also enable "App Templates" to let clients reinstall their stack using predefined configurations.

Note: The module does not modify or manage the Docker configuration on your server. All aspects of host and container security remain the responsibility of the server administrator.
For best practices and security guidelines, we recommend reviewing the OWASP Docker Security Cheat Sheet.

We will guide you step by step through the whole installation and configuration process.

The content of the package to upload should look like this.

The file is located in 'modules/servers/PortainerDockerContainers/license_RENAME.php'. Rename it from 'license_RENAME.php' to 'license.php'.

Enter your license key between quotation marks as presented on the following screen. You can find your license key in our client area → 'My Products'.

This folder is available at '/yourWHMCS/modules/addons/PortainerDockerContainers/'.
Note: It is needed for the Media Library to store uploaded images safely.

Log in to your WHMCS admin area. Go to 'System Settings' → 'Addon Modules'. Afterwards, find 'Portainer Docker Containers' and press the 'Activate' button.

To do so, click on the 'Configure' button, tick 'Full Administrator' and press 'Save Changes'.

You can access your module under 'Addons' → 'Portainer Docker Containers'.
Read the guide provided in the 'App Templates' or continue with this documentation.

In the Server Details section:

• Set Module to 'Portainer Docker Containers'
• Access Key ID / Username - this field can be skipped.
• Enter your Secret Access Key / Password - use an admin API key.
• Click Test Connection to ensure proper communication with the Portainer instance.
• Click the Configure button to select your desired environment (Portainer endpoint).
  Note: The environment defines all core settings, such as available resources (CPU, RAM, GPU) and what container or stack templates will be used.
  These are configured directly in Portainer. In the WHMCS module, you only choose from existing environments.
• After selecting the environment, the Access Hash will be filled in automatically.
• If your Portainer server uses SSL, ensure the Secure' checkbox is enabled.
  You can also enable the Override with Custom Port option and enter your custom Portainer API port.
• Finally, adjust SSO Access Control if needed, then click Save Changes.

Click on 'Create a New Group' .

To create a product click on 'Create a New Product' .

'Product Type' should be set to 'Shared Hosting'.

The App Templates section allows you to manage Docker-based applications that clients can deploy to their containers or stacks directly from the client area.
Templates are divided into four types, available under separate tabs: Container Applications, Stack Applications, Swarm and Custom Applications.
Use the interface to import, edit, group, and assign application templates to products.

• Switch between available categories: Container Applications, Stack Applications and Swarm Applications using the tabs at the top.
• Click the refresh icon to import or update the list of templates from Portainer.
• Custom Applications tab includes your templates created manually.

Navigate to 'App Templates' → 'Groups' and click on the 'Create' button.

• Name
• Description
• Items to include

For now, go back to your product's module settings and complete the configuration there.

The module should automatically save and reload settings. If not, click on 'Save Changes' manually.

• Default Instance Name - Enter the default name to be used when creating a new stack or container. The name must contain only lowercase letters, digits, hyphens (-), or underscores (_).
  Available variables: {$domain}, {$client.id}, {$service.id}, {$order.id}, {$random}.
  If left empty, the domain name will be used.

• Default Username - Enter the default username to be used when creating a new user.
  Available variables: {$domain}, {$client.id}, {$service.id}, {$order.id}, {$random}.
  If left empty, the domain name will be used.

• Open Container Console in New Window - Enable this option to open the container console in a new window when the feature is available in the client area.
• Container Network - Choose the network for container communication between services and with the external environment.
• Runtime Type - Select the OCI runtime to be used when starting the container. You can learn more about altenravie runtime types in the described use case.
• Privileged Mode - Run the container with full host privileges. Not recommended unless necessary.

• Enable Docker-in-Docker - Enable this option to run Docker inside a dedicated container for isolated client environments.
  When enabled, each service receives its own Docker-in-Docker container with an automatically installed Portainer Agent.
  This agent registers a separate node in Portainer, allowing the client’s containers or stacks to run independently from the host system.
• Runtime Type - Select the OCI runtime to be used when starting the Docker-in-Docker container (default: runc).<br/? Learn more about runtime types in the described use case.
• Container Network - Choose the network for the DinD container. The default value is bridge. Other networks may work, but on most systems only the default bridge network is supported.
• Privileged Mode - Run the container with full host privileges. Not recommended unless necessary.
• Docker Node Name - Define the template used to name and register the Portainer node for this DinD container (e.g. docker-in-docker-node-{$client.id}-{$service.id}).
  

Find more detailed information on Docker-in-Docker feature in dedicated section.

App Templates Configuration - To create instances based on stack or container applications, you must first configure the App Templates in the module's addon.
Once your applications and groups are set up there, you can select the desired application in the product's Module Settings tab to be used during instance creation.
Please refer to the App Templates and App Templates Advanced Configuration sections of the documentation for detailed setup instructions.

• Default Application Group - The groups of applications available for reinstalls. See the Groups section for more details.
• Default Application - The application that will be installed by default during container or stack creation. See the Applications section.
  Note that if applications are downloaded from the server, they will be divided into two categories: Container Applications and Stack Applications.
  Make sure to choose the default application based on the type of product you are configuring.

• Memory Reservation [MB] - Specify the amount of memory (in MB) reserved for the container. Set to 0 for no reservation.
• Memory Limit [MB] - Set the maximum amount of memory (in MB) the container can use. Use 0 for unlimited.
• CPU Limit [Cores] - Set the maximum number of CPU cores available to the container. Use 0 for unlimited.
• Volume Size [GiB] - Set the container volume size in GiB. This feature requires the Docker overlay2 driver with quota support.
  Use 0 to skip limiting; yet this solution is not recommended because it allows unlimited disk usage and may expose other containers' volumes if shared mounts are used.
  

Alternatively, you can use configurable options to allow clients to define these limits at checkout.

• Container Details - Show basic information about the container, such as status, IP address, and resource usage.
• Stack Details - Display information related to the assigned stack configuration.
• Start - Allow clients to start their container.
• Stop - Allow clients to stop their container.
• Restart - Allow clients to restart their container.
• Recreate - Allow clients to recreate their container, preserving the settings; volumes are preserved while data inside the container is reset.
• Reinstallation - Enable access to predefined application templates for quick reinstall.
• Environment Variables - Allow clients to view or manage container environment variables.
• Published Ports - Show mapped ports between the host and the container.
• Container Logs - Provide access to real-time container logs.
• Console - Allow access to the container's interactive console.
• Graph - Show performance graphs such as CPU, memory, and network usage.
• Assigned Containers - Display a list of all containers assigned to the client.
• Action Logs - Provide a history of actions performed on the container (e.g. start, stop, reinstall).

These options define what information and controls admins will see within the WHMCS service management page:

• Service Actions - Perform start, stop, or restart actions directly from the admin area.
• Stack Details - View the full configuration and status of the assigned stack.
• Assigned Containers - Display all containers linked to the service.
• Container Details - Show detailed information about the container, such as IP address, image, and resource usage.
• Published Ports - View the port mappings for the container.
• Environment Variables - View environment variables set for the container.
• Container Logs - Access logs generated by the container.
• Graphs - Display real-time resource usage graphs (CPU, RAM, network, disk I/O) per container.
• Action Logs - Review all actions performed on the container or stack from within WHMCS.

Configurable options allow clients to customize container parameters individually during the order process. If no configurable options are defined, the fixed values set in the product configuration will be used instead.

Available Configurable Options:

• app – Application
• memory_reservation – Memory Reservation
• memory_limit – Memory Limit
• max_cpu_usage – CPU Limit
• volume_size – Volume Size

Before adding it to your offer, make sure to set appropriate pricing. Create as many products as needed, each with different applications or feature sets, to tailor your offer perfectly.

• Creates a new container based on the official docker:dind image.
• Installs and starts the Portainer Agent inside it.
• Registers this container as a new node in Portainer.
• Launches the selected application, container, or stack inside this isolated Docker-in-Docker environment.
  • During Reinstall, the existing DinD container is removed and recreated.
  • During Terminate, both the DinD container and its Portainer node are deleted.
  • Suspend and Unsuspend actions remain unaffected.
    

Important: The created Docker-in-Docker container is registered as a new Portainer node. Make sure your Portainer license allows for adding additional nodes without limitation.

The DinD container extends the official docker:dind image by including the Portainer Agent.
Example image configuration:

FROM docker:dind 
RUN apk add --no-cache curl 
RUN curl -L https://downloads.portainer.io/portainer-agent-ce-static-linux-amd64.tar.gz \ | tar -xz -C /usr/local/bin \ && mv /usr/local/bin/portainer-agent /usr/local/bin/portainer-agent 
EXPOSE 9001 
COPY start.sh /start.sh 
RUN chmod +x /start.sh 
ENTRYPOINT ["/start.sh"]

• Port 2375 - Docker API (DinD)
• Port 9001 - Portainer Agent
• Other ports - dynamically assigned for client applications

The module does not modify or manage the Docker configuration on your server. All aspects of host and container security remain the responsibility of the server administrator.
Running Docker-in-Docker requires privileged containers and can expose the Docker API internally.
For secure deployments, always use TLS when exposing the Docker API and follow official security guidelines.

• Docker Docs: Protect the Docker Daemon Socket
• OWASP Docker Security Cheat Sheet

• Works with both Container and Stack types.
• Each Docker-in-Docker instance acts as a separate Portainer node.
• Traefik integration remains unchanged but works best when ports are mapped 1:1 between host and container.
• Random or mismatched port mappings may require manual configuration adjustments in Traefik.

In this short guide, you'll learn about the module's key features and how to configure them for both client and admin use.

Here, you can register products supported by the module, manage Docker templates, and access various utilities such as the media library, translation manager, and module logs.

Admins can manually edit applications, define their runtime behavior, set default values, and customize input fields in the "Setting Details" section.
There is also an option to create your own Custom Applications, which appear in the dedicated tab.

This behavior relies on two built-in variables:

• repository_url - the base URL of the template repository (e.g. https://github.com/portainer/templates)
• repository_stack_file - the path to the specific Docker Compose file in the repo (e.g. stacks/wordpress/docker-compose.yml)

These two values are automatically combined to form the full link to the stack definition:

https://github.com/portainer/templates/blob/master/stacks/wordpress/docker-compose.yml 

To customize the default stack, simply copy the Docker Compose content from the original URL and paste it into the template_stack_file field.
Once that field is filled in, only your custom configuration will be used.

Available values (based on Portainer console options):

• /bin/ash
• /bin/bash (default)
• /bin/dash
• /bin/sh

If the default command is not compatible with the container image, you can override it by editing the terminal_command setting default value.

To ensure these are parsed correctly:

• Use variable names prefixed with ENV_, e.g., ENV_MYSQL_ROOT_PASSWORD - only variables with the ENV_ prefix will be visible to clients and substituted during deployment.

• In the Compose file, use the {literal} tag around any variables to prevent parsing errors, like this:

{literal}MYSQL_ROOT_PASSWORD: ${MYSQL_ROOT_PASSWORD}{/literal}

Important: Skipping the {literal} wrapper will cause the configuration parser to fail, blocking the stack from being created.

traefik.enable=1
traefik.docker.network=bridge
traefik.http.routers.service-{$hosting.id}.entrypoints=web
traefik.http.routers.service-{$hosting.id}.rule=Host(`{$hosting.domain}`)
traefik.http.routers.service-{$hosting.id}.service=service-{$hosting.id}
traefik.http.services.service-{$hosting.id}.loadbalancer.server.port=80

The application will be deployed with these labels automatically. The placeholder variables will be parsed at runtime, ensuring correct values for each service.

Important: Make sure that both the Traefik container and the newly created service are attached to the same Docker network (e.g., bridge) to ensure routing works as expected.

Below is an example that exposes a WordPress stack through Traefik:

version: '2'

services:
   db:
     image: mysql:5.7
     volumes:
       - db_data:/var/lib/mysql
     restart: always
     network_mode: bridge
     environment:
       MYSQL_ROOT_PASSWORD: {literal}${MYSQL_DATABASE_PASSWORD}{/literal}
       MYSQL_DATABASE: wordpress
       MYSQL_USER: wordpress
       MYSQL_PASSWORD: strongpassword
     ports:
       - "{$hosting.id}6:3306"

   wordpress:
     image: wordpress:latest
     network_mode: bridge
     ports:
       - "8{$hosting.id}:80"
     restart: always
     environment:
       WORDPRESS_DB_HOST: {$params.serverip}:{$hosting.id}6
       WORDPRESS_DB_USER: wordpress
       WORDPRESS_DB_PASSWORD: strongpassword
     labels:
       traefik.enable: "true"
       traefik.docker.network: "bridge"
       traefik.http.routers.service-{$hosting.id}.entrypoints: "web"
       traefik.http.routers.service-{$hosting.id}.rule: "Host(`{$hosting.domain}`)"
       traefik.http.routers.service-{$hosting.id}.service: "service-{$hosting.id}"
       traefik.http.services.service-{$hosting.id}.loadbalancer.server.port: "80"
     

volumes:
    db_data:

To upload a new picture, click on the 'Upload Image' button.
Note: The icons used in the Media Library by default are provided by Simple Icons and are licensed under the CC0 1.0 Universal (Public Domain Dedication) license.

To delete all images at once, use the additional action button.

Its simple design makes managing various language file tweaks a smooth and efficient process. Use this built-in tool to prepare translations for the original English files.
You can also add missing or custom elements and define dynamic translations for error messages to ensure that all output, whether visible to you or your clients, is fully user-friendly.
For detailed instructions on how to use the tool, please refer to the dedicated article here.

You can filter the module logs by type with the 'Show' buttons:

• Info
• Notice
• Error
• Critical
• Total
  

All information on Logs can be found in the dedicated Logs article.

It allows you to view and interact with task details, including task IDs, statuses, and related items.
You can filter tasks, execute actions like deleting or running tasks, and even use mass actions for bulk operations.
For detailed guidance on using this tool, please refer to the dedicated article available here.

Press "i" to see service details.

• Start/stop/restart the service
• See stack details
• See assigned to the stack containers
• Action logs (more details & remove options)

• Start/stop/restart the service
• See container details
• List of published ports (IP Address, Private Port, Public Port)
• Environment Variables
• Container Logs
• Action Logs (more details & remove options)
• Container Usage Graphs: Memory Usage, CPU Usage, Network Usage and Disk I/O Usage

Additionally, you are able to set up pricing for each configurable option, which makes your offer even more competitive.

1. Firstly, manually create an order for your customer in WHMCS. Choose a client and in the summary, view click on the ' Add New Order' button. Next, select a 'Product/Service' and press 'Submit Order' .
What is important, do not perform the 'Create' action. The status has to remain as 'Pending' .
More info about placing orders can be found here
2. Proceed to the newly created product's card in your admin area. Find the following empty field:

• Instance ID
• Instance Type
• User ID
• Username

The above-mentioned information has to be consistent with the data in your Portainer panel. Now, complete this field as presented below.
Important! Remember to make sure that the format of the provided data is compatible with the format supported by the module. You can preview it for another product of the module you have already created and enter it in a similar way.
If you completed the required data, now change the status from 'Pending' to 'Active' and 'Save Changes'.

They can view service information, monitor performance, execute key actions, and deploy applications, all without needing direct access to Portainer.
Available features depend on the options enabled in the product configuration.

Service Actions that can be performed on either stack or container based product type: start, stop, and restart

Service Actions that can be performed on Stack-based product: start, stop, and restart.
Table with Stack Details with any essential stack information, including name, current status, and exposed environment variables.
Table with Assigned Containers that includes a list of all containers associated with the client’s stack.
Each entry includes the container name, status, image, IP address, and published ports.
Clicking a container entry opens a detailed view with technical and performance data.

Clicking on a container from the stack view opens a dedicated detail panel with full technical insight.
The view is divided into multiple sections for clarity and easier access to specific information.
Use the same action buttons: Start, Stop, Restart, and Recreate directly within the container view.

• Service management options
• Container details
  
• Published ports - Mappings between private and public ports.
• Environment variables - All environment variables currently assigned to the container are displayed, including sensitive configuration data and service paths.

• Service management options
• Swarm stack details
• Assigned Containers

Clicking on a container opens a dedicated detail panel with full technical insight.
The view is divided into multiple sections for clarity and easier access to specific information.
Use the same action buttons: Start, Stop, and Restart directly within the container view.

• Service management options
• Container details
  
• Published ports - Mappings between private and public ports.
• Environment variables - All environment variables currently assigned to the container are displayed, including sensitive configuration data and service paths.

• Service management options
• Container details
• Published ports
• Environment variables

Important: Reinstalling an application will permanently remove any existing container data.

Important: Reinstalling an application will permanently delete all existing container or stack data.

Each scenario focuses on a real-world need, such as defining custom networks, overriding commands, attaching volumes, or using configurable options.
Furthermore, it shows how these features can be applied to create flexible, isolated, and fully automated container environments for your clients.

This is useful when your application stack requires an internal network layer, for example, when using Traefik as a reverse proxy within the client’s isolated environment.

Network definitions are added inside the template_stack_file field of an App Template.
Each stack can create its own dedicated bridge network using dynamic variables such as proxy_{$hosting.id}, ensuring container isolation and predictable DNS-based service discovery inside the stack.

1. Navigate to: App Templates → Stacks
2. Select the application you want to configure.
3. In the template_stack_file field, define your docker-compose.yml.
4. Include a custom network declaration and attach your services to that network.
   (Example below is not a full Docker Compose file; it focuses on showing the structure.)

version: "3.9"

networks:
  proxy_{$hosting.id}:
    name: proxy_{$hosting.id}
    driver: bridge

volumes:
  db_data:

services:
  traefik:
    image: "traefik:v3.3"
    command:
      - "--providers.docker=true"
      - "--providers.docker.exposedbydefault=false"
      - "--entryPoints.web.address=:80"
    ports:
      - "80:80"
      - "8080:8080"
    volumes:
      - "/var/run/docker.sock:/var/run/docker.sock:ro"
    networks:
      - proxy_{$hosting.id}
    restart: always
    labels:
      - traefik.enable=true
      - traefik.docker.network=proxy_{$hosting.id}

  db:
    image: mysql:5.7
    restart: always
    networks:
      - proxy_{$hosting.id}
    volumes:
      - db_data:/var/lib/mysql
    environment:
      MYSQL_ROOT_PASSWORD: {literal}${MYSQL_DATABASE_PASSWORD}{/literal}
      MYSQL_DATABASE: wordpress
      MYSQL_USER: wordpress
      MYSQL_PASSWORD: strongpassword

  wordpress:
    image: wordpress:latest
    restart: always
    networks:
      - proxy_{$hosting.id}
    environment:
      WORDPRESS_DB_HOST: db:3306
      WORDPRESS_DB_USER: wordpress
      WORDPRESS_DB_PASSWORD: strongpassword
      WORDPRESS_DB_NAME: wordpress
    labels:
      - traefik.enable=true
      - traefik.docker.network=proxy_{$hosting.id}
      - traefik.http.routers.wp-{$hosting.id}.entrypoints=web
      - traefik.http.routers.wp-{$hosting.id}.rule=Host(`{$hosting.domain}`)
      - traefik.http.routers.wp-{$hosting.id}.service=wp-{$hosting.id}
      - traefik.http.services.wp-{$hosting.id}.loadbalancer.server.port=80

• Every stack may define its own internal bridge network such as proxy_{$hosting.id}.
  These networks are removed automatically when the stack is terminated.
• Traefik and application containers communicate through the internal proxy network.
  Routing is based on labels and domain rules, no need to expose additional ports to the public network.
• This setup is well-suited for isolated, self-contained applications where each stack includes its own reverse proxy layer (e.g. Traefik).

Some images require additional runtime parameters (e.g., CLI flags, passwords, startup scripts), custom port definitions, or even a completely different image tag than the one defined in Portainer.

The module allows you to override three key runtime attributes directly in an App Template:

• container_command - custom CMD instruction for the container

 (e.g., bash my-script.sh {$service.id})

• container_ports - custom list of container ports

 (e.g., ["80/tcp","443/tcp"])

• container_image - override the image and tag

 (e.g., nginx:latest)

These options enable fine-tuned deployments when the default Portainer template settings are insufficient.
All values are configured per application in the App Templates section, and the module automatically applies them during container creation or reinstall.

This use case shows how providers can attach custom volumes (both bind and local) to containers created through App Templates.
The module introduces the container_volumes configuration field, allowing you to map host paths to container directories and control read-only or read-write access.

1. Go to: App Templates → Applications
2. Open the selected application
3. Edit the container_volumes field; create it if it does not exist
4. Provide a JSON list of volume objects using Smarty-safe tags {ldelim} and {rdelim}

Each volume object contains:

• bind - path on the host (or null to allow Docker to assign a local volume)
• container - path inside the container
• readonly - true for read-only, false for read-write

Example configuration:

[
    {ldelim}
        "bind": null,
        "container": "/etc/nginx",
        "readonly": true
    {rdelim},
    {ldelim}
        "bind": null,
        "container": "/usr/share/nginx/html",
        "readonly": false
    {rdelim},
    {ldelim}
        "bind": "/opt/nginx/logs{$service.id}",
        "container": "/var/log/nginx",
        "readonly": false
    {rdelim}
]

Example explained (Nginx):

• /etc/nginx is mounted as read-only
• /usr/share/nginx/html is mounted as read-write
• /var/log/nginx stores logs in a customer-specific directory on the host:

 /opt/nginx/logs{$service.id}

Volumes displayed in Portainer may include automatically generated Docker volume IDs or bind paths, depending on configuration.

By default, Portainer executes terminal sessions as root. The module allows overriding this behavior by defining a terminal_user value in an App Template.

This is useful when:

• root access is not desired,
• the application requires running commands as a specific user (e.g., www-data for WordPress),
• the image defines multiple system users, and one of them should be used for security or compatibility reasons.

How to set a custom terminal user

1. Go to: App Templates → Applications
2. Open the application you want to modify
3. Add or edit the terminal_user setting
4. Enter a username that exists inside the Docker image
   (e.g., www-data, node, postgres, or a numeric uid / uid:gid pair)

The terminal user must match one of the following formats:

• user
• user:group
• uid
• uid:gid
  

Portainer will reject values that do not exist in /etc/passwd inside the container.

Behavior on deployment & reinstall

• If terminal_user is defined → the module uses it for the terminal session
• If not defined → the user defaults to root
• During reinstall, the correct terminal user is restored automatically (stored in WHMCS custom fields for persistence)

To run terminal commands as the web server user instead of root, define:

terminal_user = www-data

This prevents errors such as: unable to find user rootXXXXX: no matching entries in passwd file which occurs when a non-existent user is set.

This allows providers to pass user-selected parameters—such as disk size, limits, GPU flags, memory settings, and so on - directly into Docker Compose YAML, labels, or environment variables during stack creation.

Configurable Options become available inside App Template fields using the {$params.configoptions.*} variable.

How to use Configurable Options inside a stack

1. Create or edit a WHMCS Configurable Options Group (e.g., Disk Size, CPU Limit, Memory Limit).
   
2. Assign these options to your product that uses Portainer Docker Containers.
   
3. Go to: App Templates → Applications → Application details.
4. Edit the field where you want to use the value (e.g., labels, template_stack_file, environment, etc.).
5. Insert the CO variable using:

{$params.configoptions.option_name}

The module automatically injects the current value when creating or reinstalling the service.

Example: Passing "Disk Size" from WHMCS to container labels
If you defined a Configurable Option:

• disk_size = 15 MB

Then inside the App Template → labels field you can use:

traefik.enable=1
traefik.docker.network=bridge
disk_customoption={$params.configoptions.disk_size}

During service creation, this will appear in Portainer as:

disk_customoption = 15

Example inside docker-compose (template_stack_file)
You can also use CO values inside stack compose files:

version: "3.9"

services:
  app:
    image: ubuntu:latest
    environment:
      DISK_SIZE: "{$params.configoptions.disk_size}"
    labels:
      - "disk.size={$params.configoptions.disk_size}"

This use case shows how container isolation can be improved by using an alternative container runtime instead of the default one.
The module allows administrators to choose the runtime used to start containers, which helps limit container privileges.

To select a different runtime, open the product module settings and choose the Runtime option in either the Configuration or Docker-in-Docker Configuration section.

Example: Using Sysbox Runtime
One example of an alternative runtime is Sysbox.

Sysbox improves container isolation by:

• using Linux user namespaces (container root has no host privileges),
• hiding host system details inside the container,
• virtualizing selected parts of procfs and sysfs,
• locking initial container mounts.

Running System-Level Software
Sysbox also allows containers to run system-level software that normally requires elevated privileges, such as:

• systemd
• Docker and Docker-in-Docker
• Kubernetes / K3s
• buildx (including multi-architecture builds)

These workloads can run without privileged containers or special images.

Important Notes

• Alternative runtimes can improve container separation compared to the default runtime.
• When Docker-in-Docker is used together with Sysbox, Privileged Mode is not required.
• The module does not install or manage container runtimes on the host, the selected runtime must be installed and maintained by the server administrator.

Take a moment to review the Translations Tool documentation and its Missing Elements section to ensure all custom lines are properly translated.

Ensure successful completion of the module update by carefully following each step, thereby preventing data loss or any unforeseen issues.
Additionally, you will find a current list of supplementary actions necessary for a smooth update process there.

Opt for the Open Source version of your Portainer Docker Containers For WHMCS module to unlock these benefits.
Simply click on either the Get Source Code or Upgrade To Lifetime button found on the product's page in our client area to complete the one-step upgrade process, with a dedicated discount already applied.

Follow a comprehensive guide covering the transition process, the advantages it brings, and step-by-step instructions on what to do next after the order has been successfully finalized.