This guide provides documentation for Wickr IO Integrations. If you're using AWS Wickr, see AWS Wickr Administration Guide.

Wickr IO clients troubleshooting

These are troubleshooting suggestions associated with running the Wickr IO gateway, clients, and integrations. You may also run into some issues when developing your own custom Wickr IO integrations.

This section will describe some possible issues you may run into while using the Wickr IO client and the associated services

Bot runtime architecture

Each Wickr IO bot has three layers, which AWS recommends independent monitoring for:

The container can report as running while the bot process inside it has crashed or lost its connection to the Wickr network. Effective monitoring covers all three layers.

Setting up Wickr IO Docker container

Cannot load Docker image

If you receive the following error then you may have to make sure you have permissions to access the unix socket to communicate with the Docker engine:

docker: Got permission denied while trying to connect to the Docker daemon socket at unix:...

Solution:

For help setting the appropriate permissions for you Docker account, see Linux post-installation steps for Docker Engine

Wickr IO Fails startup due to directory permissions

When running the Docker container on a Mac system, you may encounter a failure when starting the Wickr IO Docker container if you have not changed the write permissions for the /opt directory. This issue typically arises after the ./start.sh command. You will see the following errors:

  "QIODevice::write (QFile, "/opt/WickrIO/logs/WickrIOSvr.output"): device not open
terminate called after throwing an instance of 'zmq::error_t'
what(): No such file or directory
./start.sh: line 3: 7 Aborted WickrIOSvr"
 

This issue has only been seen on Mac systems. It occurs when a user creates the /opt directory as the root, and then runs the container as a user.

Solution:

This is caused by a permission issue in the /opt directory. To resolve the issue, change the permissions of the /opt/WickrIO directory (or the name of the directory you created for your installation) to make it writeable. The following command will fix this problem:

chmod 777 /opt/WickrIO
  

Host system running out of disk space

Your system is low on storage, preventing you from downloading and running a new Docker container. This issue may arise if you have not removed old Docker containers from your system.

Solution:

Docker Mounts denied Error

You're getting the following error: docker: Error response from daemon: Mounts denied: The path /opt/WickrIO is not shared from OS X and is not known to Docker.

Solution:

Restart Docker.

Wickr IO Not working on Mac M1 hosts

The Wickr IO Docker images are not built to run on the Mac M1 hosts. During our testing of the Mac M1 hardware, we discovered an issue related to the interaction exec() commands, which led to failures when trying to start a bot from the command line interface (CLI).

Solution:

If you want to run the Wickr IO Docker images on Mac M1 hardware, follow these steps:

Provisioning Wickr IO client

Bot client provisioning failures

When adding a bot client to a Docker image, you may encounter issues during the provisioning step. This can occur for both new and existing clients. Below are some common problems you might face:

Username does not exist:

Solution

Make sure the bot username is correct and exists in the Wickr Admin Console.

Incorrect password:

Solution

Make sure the password entered is correct. It should match the one used when creating the bot user in the Wickr Admin Console.

Start bot client failures

Incorrect password

When trying to start a bot client, if you enter an incorrect password, you will get a “Bus Error” and see the Docker container has exited.

Solution

Wickr IO client does not start

If your Wickr IO client isn't starting and the previous solutions haven't resolved the issue, try the following steps. First, check if the client is running by using the ps command. Enter the following command in the terminal:

ps -aef | grep wickrio_bot

This command should return an entry for each Wickr IO client that is currently running. Additionally, the command line interface of the Wickr IO Docker container includes various commands that can help you diagnose any client issues.

Wickr IO command line interface

Wickr IO client is not running.

Once the client has started, it should remain in the Running state unless it is manually paused or deleted. If, at any point, your client enters a Down or Not Running state unexpectedly, follow the solution below.

Solution:

Try restarting the Wickr IO client using the restart command. If the issue continues, check the provisioning and client logs for more information, and then contact Wickr Support.

Turn on debugging in Wickr IO CLI

If you are facing issues with performing any operation using the Wickr IO command line interface like adding or deploying a custom bot , this procedure will help you view more detailed debugging information on the command line interface.

Solution

To enable debugging, enter debug in the CLI.

Client and Integration compatibility issues

With the release of new Wickr IO Docker images containing changes to the Wickr IO Add-on APIs, when you upgrade your container to use the new version, it is possible there will be compatibility issues that will cause Integrations to not work.

Solution

If you are running an officially Wickr supported integration, you will see the Needs Upgrade text on your Wickr IO client.

To upgrade your integration to avoid any compatibility issues, complete the following steps.

If you are using a custom integration, make sure to update your integration to ensure compatibility with the updated Wickr IO container.

If you need to contact Wickr support it's helpful to have the version number of the Docker container ready. You can find the version number by using the version command in the Wickr IO command line interface. Additionally, new versions of the Wickr IO Docker image will display the version numbers of the integrations when you run the list command. When addressing integration issues, having the version numbers for the integrations will also be beneficial.

Deploying custom Integrations

Cannot import a custom integration

If the necessary files are missing from the software.tar.gz imported into the Docker container, you will receive an "install shell file does not exist" error when starting a Wickr IO client using your custom integration.

Solution

Make sure all the required files are present in the zipped integration software imported in the docker container. You can use any sample integrations as reference.

Monitor bot health with Amazon CloudWatch

The following table summarizes the monitoring approaches for each layer, from simplest to most comprehensive.

For production bots, we recommend implementing all four approaches. They are not redundant – each catches different failure modes.

Monitor the host instance

Use the built-in Amazon EC2 StatusCheckFailed metric to detect host-level failures. On supported instance types, Amazon EC2 simplified automatic recovery is enabled by default and automatically migrates the instance to healthy hardware when a status check fails. The alarm below is informational – it notifies you that a recovery occurred, but no manual action is required. For more information, see Recover your instance in the Amazon EC2 User Guide.

HostDownAlarm:
  Type: AWS::CloudWatch::Alarm
  Properties:
    AlarmName: !Sub "${BotName}-HostDown"
    Namespace: AWS/EC2
    MetricName: StatusCheckFailed
    Dimensions:
      - Name: InstanceId
        Value: !Ref BotInstance
    Statistic: Maximum
    Period: 60
    EvaluationPeriods: 2
    Threshold: 1
    ComparisonOperator: GreaterThanOrEqualToThreshold
    AlarmActions:
      - !Ref AlertTopic

Monitor the Docker container

Create a script on the host that publishes a custom CloudWatch metric based on container status. Run it every minute using cron. For example:

#!/bin/bash
# /opt/wickr-bot/monitor.sh
CONTAINER_NAME="${1:-wickr-bot}"
NAMESPACE="WickrIO/Bots"

STATUS=$(docker inspect --format='{{.State.Running}}' "$CONTAINER_NAME" 2>/dev/null)

aws cloudwatch put-metric-data \
  --namespace "$NAMESPACE" \
  --metric-name ContainerRunning \
  --dimensions BotName="$CONTAINER_NAME" \
  --value "$([ "$STATUS" = "true" ] && echo 1 || echo 0)" \
  --unit Count

Add a cron entry to run the script:

* * * * * /opt/wickr-bot/monitor.sh container-name

Create an alarm that fires when the value drops to 0.

Monitor with log-based metric filters

If you forward container logs to Amazon CloudWatch Logs using the awslogs driver, you can create a metric filter that counts log events. When the container stops producing output, the alarm fires.

Add a heartbeat metric (recommended)

A heartbeat metric is the most reliable approach because it proves the Node.js process is alive and the event loop is not blocked. Add the following to your bot's entry point, after the bot starts successfully. For example:

const { CloudWatchClient, PutMetricDataCommand } = require('@aws-sdk/client-cloudwatch')
const cw = new CloudWatchClient()
const BOT_NAME = process.env.BOT_NAME || 'wickr-bot'

setInterval(async () => {
  try {
    await cw.send(new PutMetricDataCommand({
      Namespace: 'WickrIO/Bots',
      MetricData: [{
        MetricName: 'Heartbeat',
        Dimensions: [{ Name: 'BotName', Value: BOT_NAME }],
        Value: 1,
        Unit: 'Count'
      }]
    }))
  } catch (e) { console.error('Heartbeat publish failed:', e.message) }
}, 60000)

Add the @aws-sdk/client-cloudwatch dependency to your bot's package.json.

Create an alarm on the heartbeat metric. For example:

BotProcessAlarm:
  Type: AWS::CloudWatch::Alarm
  Properties:
    AlarmName: !Sub "${BotName}-ProcessDown"
    Namespace: WickrIO/Bots
    MetricName: Heartbeat
    Dimensions:
      - Name: BotName
        Value: !Ref BotName
    Statistic: Sum
    Period: 300
    EvaluationPeriods: 2
    Threshold: 1
    ComparisonOperator: LessThanThreshold
    TreatMissingData: breaching
    AlarmActions:
      - !Ref AlertTopic

Set TreatMissingData to breaching so the alarm fires when the metric stops arriving entirely, rather than entering INSUFFICIENT_DATA.

Monitor memory usage

Node.js bots that maintain session state, cache data, or process file attachments can develop memory leaks over time. If the bot's memory usage exceeds the Docker container's memory limit, Docker terminates the container with an out-of-memory (OOM) kill. The container restarts automatically if you configured the --restart policy, but active user sessions and in-flight messages are lost.

To detect memory growth before it causes an OOM kill, publish the Node.js heap usage alongside your heartbeat metric. For example:

setInterval(async () => {
  const mem = process.memoryUsage()
  try {
    await cw.send(new PutMetricDataCommand({
      Namespace: 'WickrIO/Bots',
      MetricData: [
        {
          MetricName: 'Heartbeat',
          Dimensions: [{ Name: 'BotName', Value: BOT_NAME }],
          Value: 1, Unit: 'Count'
        },
        {
          MetricName: 'HeapUsedMB',
          Dimensions: [{ Name: 'BotName', Value: BOT_NAME }],
          Value: Math.round(mem.heapUsed / 1048576),
          Unit: 'Megabytes'
        }
      ]
    }))
  } catch (e) { console.error('Metric publish failed:', e.message) }
}, 60000)

Create a CloudWatch alarm that fires when heap usage exceeds 80% of the container's memory limit. For example, if the container has a 512 MB memory limit (--memory=512m), set the threshold to 410 MB. Adjust the threshold to 80% of your configured limit.

MemoryAlarm:
  Type: AWS::CloudWatch::Alarm
  Properties:
    AlarmName: !Sub "${BotName}-HighMemory"
    Namespace: WickrIO/Bots
    MetricName: HeapUsedMB
    Dimensions:
      - Name: BotName
        Value: !Ref BotName
    Statistic: Maximum
    Period: 300
    EvaluationPeriods: 3
    Threshold: 410
    ComparisonOperator: GreaterThanThreshold
    AlarmActions:
      - !Ref AlertTopic

Remediation

Required IAM permissions

The Amazon EC2 instance profile for the bot host requires the following permissions for Amazon CloudWatch monitoring:

{
    "Version": "2012-10-17", 
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "cloudwatch:PutMetricData",
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "logs:CreateLogGroup",
                "logs:CreateLogStream",
                "logs:PutLogEvents"
            ],
            "Resource": [
                "arn:aws:logs:*:*:log-group:/wickr/bots/*",
                "arn:aws:logs:*:*:log-group:/wickr/bots/*:*"
            ]
        }
    ]
}

Collect bot logs

A Wickr IO bot produces logs at multiple levels. Understanding where each log is stored helps you collect the right information when troubleshooting.

To view the integration log from outside the container:

sudo docker exec container-name \
  cat /opt/WickrIO/clients/bot-name/integration/bot-name/logs/log.output

To view the WickrIO server log:

sudo docker exec container-name cat /opt/WickrIO/logs/WickrIOSvr.log

View Docker container logs

# View recent logs
sudo docker logs --tail 100 container-name

# Follow logs in real time
sudo docker logs -f container-name

Configure integration log settings

The WickrLogger library reads log settings from the processes.json file in your bot's integration directory. Add a log_tokens section to configure the log level, maximum file size, and maximum number of rotated log files:

{
  "apps": [{
    "name": "bot-name",
    "script": "src/index.js",
    "env": {
      "tokens": { },
      "log_tokens": {
        "LOG_LEVEL": "debug",
        "LOG_FILE_SIZE": "10m",
        "LOG_MAX_FILES": "5"
      }
    }
  }]
}

The defaults are info level, 10 MB maximum file size, and 5 rotated files. Set LOG_LEVEL to debug temporarily when troubleshooting, then revert to info for normal operation. For more information, see Logging API in the Wickr IO Bot Guide.

Configure Docker log rotation

Set the max-size and max-file options when you start the container. For example:

sudo docker run -it \
  --restart unless-stopped \
  --log-opt max-size=50m \
  --log-opt max-file=5 \
  other-options \
  image-name

This configuration keeps up to 5 log files of 50 MB each (250 MB total). To set this as the default for all containers on the host, add the following to /etc/docker/daemon.json and restart Docker:

{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "50m",
    "max-file": "5"
  }
}

Forward logs to Amazon CloudWatch Logs

For production bots, you can forward container-level logs to Amazon CloudWatch Logs using the Docker awslogs log driver. This captures WickrIO server output and container startup messages, which is useful for detecting container crashes and restart loops. To forward bot application logs to Amazon CloudWatch Logs, use the CloudWatch agent on the host to tail the volume-mounted integration log file, or publish metrics directly from your bot code using the heartbeat approach described in Add a heartbeat metric (recommended).

sudo docker run -it \
  --restart unless-stopped \
  --log-driver=awslogs \
  --log-opt awslogs-region=us-east-1 \
  --log-opt awslogs-group=/wickr/bots/bot-name \
  --log-opt awslogs-create-group=true \
  other-options \
  image-name

The Amazon EC2 instance profile must include the logs:CreateLogGroup, logs:CreateLogStream, and logs:PutLogEvents permissions.

Archive logs to Amazon S3

For compliance or long-term retention, export Amazon CloudWatch Logs data to Amazon S3. You can configure automatic export using a Amazon CloudWatch Logs subscription filter with Amazon Data Firehose, or perform one-time exports from the Amazon CloudWatch console. For more information, see Export log data to Amazon S3 in the Amazon CloudWatch Logs User Guide.

Set a retention policy on the Amazon CloudWatch Logs log group to control costs. For most bot deployments, 30 to 90 days of log retention in Amazon CloudWatch Logs is sufficient for troubleshooting, with older logs archived to Amazon S3.

Common issues

Exited Docker container

Once the Wickr IO container is set up, it is designed to run indefinitely unless stopped manually. However, unexpected events may occur that could cause your running Docker container to exit.

Solution

Exited Docker container

Once you have a running bot client, you should be able to interact(depends on the integration type) with it on Wickr client application. If the bot is not responding as expected see the solution below to debug the issue.

Solution

Too many bot devices

Bot clients do not automatically remove old devices upon start-up. If you frequently move a bot between different machines, you may reach the limit of 50 devices. Each time you move the bot to a new device or recreate it, a new device entry is created. Once you reach this limit of 50 devices, the bot may stop functioning properly.

Solution

Starting from version 5.81, there are multiple ways to clear out old bot devices. To do this, you need to modify the bot's .ini file. This is a one-time setting that the bot client will use to eliminate old devices. The setting will specify the number of seconds a bot device has remained logged in. If a device's last login exceeds this specified duration, it will be suspended. For example:

[oneshot]
suspenddeviceafterseconds=120

In the example, you can set the value to 120 seconds (or two minutes). This setting will NOT affect the current device but will suspend all devices that have not logged in within the specified time frame. The .ini file can be found in the client directory associated with the bot client. For example:

/opt/WickrIO/clients/[botname]/WickrIO[botname].ini

Restart the bot after you have added this to the .ini file.

Wickr files are not received or transmitted

If the Wickr IO integration you are using requires sending or receiving files but you're experiencing issues with either, it may be due to an inaccurate date and/or time setting on your system. Wickr's system relies on the host date and time to transfer encrypted files successfully. If these setting are incorrect, file transfers will fail.

Solution

For accuracy, it's recommended to install and run an NTP (Network Time Protocol) service on your host system.

Network timeouts

If your bot is failing to interact with the backend servers and the logs indicate time errors, there is a way to increase the timeout for network requests. While this may not resolve the underlying problem, it can help rule out timeout as a cause of connection issues.

Solution

To adjust the network timeouts, you'll need to modify the .ini file for the bot client. The /opt/WickrIO/clients/WickrIO.ini is the appropriate file.

Add the following below to the .ini file:

[networksetup]
requesttimeout=[some value in seconds]
userrequesttimeout=[some value in seconds]

The .ini file is located in the client directory associated with the bot client, for example:

/opt/WickrIO/clients/[botname]/WickrIO[botname].ini

Restart the bot after you have added this to the .ini file.

Bot doesn't respond to messages

Possible causes:

Resolution

Failed to create connection to host

The bot container logs show Failed to create connection to host when attempting to reach the Wickr messaging gateway on port 443. The bot cannot connect to the Wickr service and will not come online.

Possible causes:

Resolution

Container starts but bot process fails

Possible causes:

Resolution

Bot was working but stopped after container recreation

If you removed and recreated the container (using docker rm followed by docker run) instead of restarting it (using docker restart), the WickrIO server's registration database was lost. The container starts, but the WickrIO server does not recognize any registered bot clients.

Symptoms:

Resolution

To prevent this issue, use docker restart instead of docker rm and docker run. If you must recreate the container (for example, to change the log driver), plan for the re-registration step.

Bot is online but CloudWatch alarms are not working

Possible causes:

Resolution

Bot integration does not start after container restart

The container is running and the WickrIO server shows the bot as Running, but the bot does not respond to messages and no integration log is produced.

Cause: When the container restarts in detached mode, the WickrIO server starts the Wickr client process but does not automatically launch the Node.js integration. The integration must be started separately.

Resolution

Integration import fails with "install shell file does not exist"

When importing a custom integration during the add command, the WickrIO console reports install shell file does not exist for this software! and the import fails.

Cause: The software.tar.gz file does not contain an install.sh script. The WickrIO import process requires this script to install the integration dependencies.

Resolution: Add an install.sh script to the root of your software.tar.gz archive:

#!/bin/bash
cd "$(dirname "$0")"
npm install --production

Rebuild the archive with the script included:

tar czf software.tar.gz src/ package.json install.sh

Upgrading bots

The WickrIO bots do not automatically upgrade, like a Wickr client does. You will need to periodically and manually upgrade the bots to make sure you have the latest software.

Solution

The following are the steps you will perform to upgrade a WickrIO docker image and the associated bots:

The following is sample output from upgrading an old WickrIO bot running version v4.64.9.3, with a wickrio_web_interface bot. The version being upgraded to is the 5.116.18.01 version/tag.

Enter command:list
Current list of clients:
 client[0] old-test-bot, State=Running, Integration=wickrio_web_interface
Enter command:version
version: v4.64.9.3
Enter command:pause 0
Do you really want to pause the client with the name old-test-bot (default: yes):yes
Enter command:list
Current list of clients:
 client[0] old-test-bot, State=Paused, Integration=wickrio_web_interface
Enter command:read escape sequence
ubuntu@mybothost:~$ 
docker kill VeryOldBot
ubuntu@mybothost:~$ 
docker rm -f VeryOldBot
ubuntu@mybothost:~$ 
docker run -v /opt/VeryOldBot/WickrIO:/opt/WickrIO -p 4444:4444 -d --restart=always --name="VeryOldBot" -ti wickr/bot-cloud:latest
Unable to find image 'wickr/bot-cloud:latest' locally
5.116.18.01: Pulling from wickr/bot-cloud
4bbfd2c87b75: Already exists 
d2e110be24e1: Already exists 
889a7173dcfe: Already exists 
20ca454721b1: Already exists 
02c4b05cb492: Already exists 
1c731f8c023d: Already exists 
fcd34fc70cfe: Already exists 
b1fceb668295: Already exists 
68307b81514b: Pull complete 
b9f674e60307: Pull complete 
e4fd99322c5a: Pull complete 
3fdf8c473cd1: Pull complete 
9dd71d5d554c: Pull complete 
225a5f4a7590: Pull complete 
Digest: sha256:05f7d0df8a488f7e325845423d13ebda95b1967b7b00203fe2425ae35e43480f
Status: Downloaded newer image for wickr/bot-cloud:latest
71bb0c85bc4c4c92db604136ad9f64e62d9769debcfccb656794037b4dc06d44
ubuntu@mybothost:~$ docker attach VeryOldBot 

Updating integration software version numbers
Updating integration software version numbers
Searching NPM registry
Searching NPM registry

Welcome to the WickrIO Console program (v5.116.18.01)

Current list of clients:
#  Name          Status  Integration            Version  Events  Misc
======================================================================
0  old-test-bot  Paused  wickrio_web_interface  1.1.2    2       Needs Upgrade!
Enter command:
Enter command:upgrade 0
Upgrading from version 1.1.2 to version 5.82.2
Okay to proceed? (default: yes):yes
Copying wickrio_web_interface software

Upgrading wickrio_web_interface software
Installing wickrio_web_interface software
Installing
Installing
Begin configuration of wickrio_web_interface software for old-test-bot
Now using node v12.20.2 (npm v6.14.11)
adminsOptional=false
adminsOptional=false
Finished Configuring package!
Finished Configuring forever!
Finished Configuring!
Enter command:list
Current list of clients:
#  Name          Status  Integration            Version  Events  Misc
======================================================================
0  old-test-bot  Paused  wickrio_web_interface  5.82.2   2       
Enter command:start 0
Preparing to start the client with the name old-test-bot
Do you really want to start the client with the name old-test-bot:yes
Enter command:list
Current list of clients:
#  Name          Status   Integration            Version  Events  Misc
=======================================================================
0  old-test-bot  Running  wickrio_web_interface  5.82.2   3       
Enter command:

Improve bot resilience

A Wickr IO bot running on a single Amazon EC2 instance is a single point of failure. If the instance fails, the bot is offline until you manually intervene. The following practices improve bot availability for production deployments.

Persist container state across restarts

The Wickr IO container stores critical state in two locations that you must mount as Docker volumes to persist across container restarts:

The following example shows the recommended volume mounts:

sudo docker run -it \
  --name bot-name \
  --restart unless-stopped \
  -e PRODUCT_TYPE=govcloud \
  -v /opt/wickr-bot:/opt/WickrIO/clients/bot-name/integration \
  -v /opt/wickr-bot-client:/opt/WickrIO/clients/bot-name/client \
  image-name

Enable automatic instance recovery

Amazon EC2 simplified automatic recovery is enabled by default on supported instance types. If the underlying hardware fails, AWS automatically migrates the instance to healthy hardware. The instance retains its ID, IP addresses, and attached EBS volumes. For more information, see Automatic instance recovery in the Amazon EC2 User Guide.

Automate bot recovery with health checks

The Docker --restart unless-stopped policy restarts the container when it exits, but it does not detect cases where the container is running while the bot process inside it has stopped responding. To detect and recover from these silent failures, add a Docker health check.

Create a health check script in your bot's integration directory that verifies the bot process is running and producing logs. For example:

#!/bin/bash
# healthcheck.sh — exit 0 = healthy, exit 1 = unhealthy

# Check that the Node.js bot process is running
pgrep -f "node entry-point" > /dev/null || exit 1

# Check that the bot has produced a log entry in the last 5 minutes
LOG="/opt/WickrIO/clients/bot-name/integration/bot-name/logs/log.output"
if [ -f "$LOG" ]; then
  LAST_MOD=$(stat -c %Y "$LOG" 2>/dev/null || stat -f %m "$LOG" 2>/dev/null)
  NOW=$(date +%s)
  DIFF=$(( NOW - LAST_MOD ))
  [ "$DIFF" -gt 300 ] && exit 1
fi

exit 0

Start the container with the health check configured. For example:

sudo docker run -it \
  --restart unless-stopped \
  --health-cmd="/opt/WickrIO/clients/bot-name/integration/healthcheck.sh" \
  --health-interval=60s \
  --health-retries=3 \
  --health-start-period=120s \
  other-options \
  image-name

The --health-start-period gives the bot time to authenticate with the Wickr network before health checks begin. After the start period, Docker runs the health check every 60 seconds. If 3 consecutive checks fail, Docker marks the container as unhealthy.

#!/bin/bash
# /opt/wickr-bot/watchdog.sh — run via cron every 2 minutes
CONTAINER="container-name"
HEALTH=$(docker inspect --format='{{.State.Health.Status}}' "$CONTAINER" 2>/dev/null)

if [ "$HEALTH" = "unhealthy" ]; then
  logger "Wickr bot $CONTAINER is unhealthy — restarting"
  docker restart "$CONTAINER"
fi

*/2 * * * * /opt/wickr-bot/watchdog.sh

Using docker restart preserves the WickrIO registration database and container logs.

Use an Auto Scaling group

An Auto Scaling group with a minimum, maximum, and desired capacity of 1 automatically replaces the instance if it fails a health check. Store your bot's client data and integration code on a separate Amazon EBS volume or Amazon EFS file system so the replacement instance can mount the same data and resume without re-registering the bot. For more information, see the Amazon EC2 Auto Scaling User Guide.

Use a container orchestrator

If your organization already uses a container orchestrator such as Amazon ECS, Amazon EKS, or a lightweight Kubernetes distribution, you can run the Wickr IO container as a managed task or pod with built-in health checks, automatic restarts, and log collection. This approach is recommended only if you already have orchestration infrastructure in place.