Move to production

This guide walks you through the mandatory steps to move your Gluesync deployment from evaluation to a production-ready state. It covers everything from system validation and container runtime configuration to final security and operational checks.

If you installed Gluesync using one of our setup wizards (default installers), you are approximately 99% ready for production. The wizards handle most of the heavy lifting: system checks, container runtime installation, kit download, encryption key generation, and initial startup.

What remains for you to complete manually:

Validate system requirements

Before installing or promoting any environment, confirm that the host meets the hardware baseline (CPU, memory, and free disk space) documented in System requirements. Size the host against the production profile, not the POC/demo one, and add storage headroom for container images, logs, Prometheus metrics, and backups.

Our setup wizards enforce these requirements automatically, but if you are performing a manual installation you must verify them yourself.

Network

The host must be able to reach the following endpoints:

  • hub.docker.com or registry-1.docker.io (for container image pulls)

  • api.backoffice.molo17.com (for license and kit validation)

A TCP connection test to registry-1.docker.io:443 should succeed.

Install and configure the container runtime

Gluesync runs as a set of containers. The production host must have a supported container runtime installed, configured with logging limits, and running as a service.

Docker (Linux)

  1. Install Docker CE and the Compose plugin for your distribution:

    • Fedora: dnf install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

    • Ubuntu/Debian: apt-get install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

    • Red Hat/Oracle Linux/CentOS: yum install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

    • Amazon Linux 2023: dnf install docker

    • SUSE Linux Enterprise Server / openSUSE: zypper install docker

  2. Start and enable the Docker service:

    systemctl enable --now docker

  3. Add your deployment user to the docker group (optional but recommended):

    usermod -aG docker $USER

  4. Configure the Docker logging driver to prevent disk exhaustion. Create or edit /etc/docker/daemon.json:

    {
    "log-driver": "json-file",
    "log-opts": {
        "mode": "non-blocking",
        "max-buffer-size": "4m",
        "max-size": "100m",
        "max-file": "10"
    }
}

  5. Restart Docker to apply the logging configuration:

    systemctl restart docker

Podman (Linux, rootless)

  1. Install Podman and CNI plugins for your distribution.

  2. Enable user lingering so rootless services persist across logouts:

    loginctl enable-linger $USER

  3. Configure subuid/subgid for rootless containers:

    echo "$(whoami):100000:65536" | sudo tee -a /etc/subuid
echo "$(whoami):100000:65536" | sudo tee -a /etc/subgid

  4. Enable the Podman socket for your user:

    systemctl --user enable --now podman.socket

  5. Configure Podman logging in ~/.config/containers/containers.conf:

    [containers]
log_driver = "k8s-file"
log_size_max = 104857600

  6. Configure registries in ~/.config/containers/registries.conf:

    [registries.search]
registries = ["docker.io"]

Docker (Windows Server)

  1. Verify the host is running Windows Server 2019, 2022, or 2025.

  2. Enable the Containers Windows feature.

  3. If using Hyper-V containers, also enable the Hyper-V feature.

  4. Install Docker Engine and Docker Compose.

  5. Configure the Docker daemon logging options in %programdata%\docker\config\daemon.json with the same json-file rotation settings shown for Linux above.

  6. Start the Docker service.

Windows Server 2019 support is approaching end-of-life. Docker, Traefik, and other dependencies are no longer receiving security patches on this platform. Plan a migration to Windows Server 2022 or newer.

Apply network tuning (Linux)

For Ubuntu and Debian systems, apply the following sysctl tuning to improve container networking performance. Create /etc/sysctl.d/99-gluesync.conf:

net.netfilter.nf_conntrack_max = 131072
net.netfilter.nf_conntrack_tcp_timeout_time_wait = 30
net.core.rmem_max = 134217728
net.core.wmem_max = 134217728

Then reload:

sudo sysctl --system

Antivirus software

Antivirus and endpoint detection & response (EDR) tools that perform real-time file-system scanning can cause significant CPU overhead on the host running Gluesync. Gluesync continuously reads and writes to its data directory (SQLite databases, journal files, log files, and internal caches), which makes it a high-frequency I/O target. Every file operation that triggers an antivirus scan adds latency and CPU cycles that compete directly with pipeline processing.

Depending on the antivirus product and the scan policy in use, this interference can:

  • Spike CPU usage on the Gluesync host by 20–80% under normal load

  • Introduce unpredictable latency spikes in CDC pipelines

  • Cause container health-check timeouts

  • Slow down Gluesync startup significantly

If Gluesync appears to be running slowly, consuming unexpected CPU, or if pipelines are experiencing intermittent lag with no other obvious cause, antivirus real-time scanning is one of the first things to rule out.

Recommended action: whitelist the Gluesync installation directory

The safest and most targeted fix is to add the Gluesync installation directory to your antivirus exclusion list (also called a whitelist or safe path).

Platform Default path to exclude

Linux (Docker / Podman)

/opt/gluesync

Windows Server (Docker)

C:\Program Files\Gluesync

If your organisation uses a non-default installation path, exclude that path instead.

In addition to the installation directory, consider also excluding:

  • The Docker data root (default: /var/lib/docker on Linux, C:\ProgramData\Docker on Windows) to avoid scanning container layer files

  • The Podman storage root (default: ~/.local/share/containers/storage) for rootless Podman deployments

Alternative: disable real-time scanning on the host

If whitelisting specific paths is not possible under your security policy, disabling real-time (on-access) scanning entirely on the Gluesync host is an acceptable alternative, provided the host is otherwise network-isolated and hardened. Scheduled (on-demand) scans can remain active outside of peak pipeline hours.

Coordinate any exception with your security team and document it in your change management process.

Deploy the Gluesync kit

  1. Create the installation directory:

    • Linux: /opt/gluesync

    • Windows: C:\Program Files\Gluesync

  2. Download your kit using the unique identifier from your Gluesync welcome email.

  3. Extract the archive.

  4. Copy the contents of the platform-specific folder (gluesync-docker, gluesync-podman, or gluesync-docker-windows) into the installation directory.

  5. Copy any shared root-level configuration files (for example, bootstrap-core-hub.json) into the same directory, excluding other platform folders.

Set ownership and permissions

  • Docker (Linux): Ensure the installation directory is owned by the user that will run Gluesync:

    sudo chown -R $(whoami):$(whoami) /opt/gluesync

  • Podman (Linux): Ensure the installation directory is owned by the actual user running rootless Podman:

    sudo chown -R $SUDO_USER:$SUDO_USER /opt/gluesync

  • Windows: The default install path under C:\Program Files\Gluesync is managed by the setup wizard.

Generate a storage encryption key

Gluesync uses a storage key to encrypt sensitive data at rest. The trial kit ships with a placeholder key (gluesync-storage-key). You must replace it with a randomly generated key before going live.

In bootstrap-core-hub.json, replace the placeholder:

{
  "storageKey": "<your-random-32-char-hex-key>"
}

If you used a setup wizard, this step was completed automatically.

Start Gluesync

  1. Change to the installation directory and run the startup script:

    • Linux: ./run.sh

    • Windows: run.ps1

  2. Wait for all containers to reach a healthy state.

  3. Access the Control Plane:

Production readiness checklist

After Gluesync is running, complete the following tasks to reach full production readiness.

Logging

  • Set log verbosity to INFO or WARN to reduce noise and disk usage.

  • Confirm log rotation is active (see the container runtime logging configuration above).

  • Review Logging configuration for advanced options.

Alerting

  • Configure SMTP so Gluesync can send email notifications.

  • Verify alert rules are enabled for pipeline errors, license expiry, and disk space.

Security

Backup and restore

  • Schedule regular Automator backups from the Control Plane.

  • Store backup artifacts in a safe location, separate from the Gluesync host.

  • Test a restore in a lower environment to validate your disaster recovery runbook.

Monitoring

Antivirus exclusions

  • Add the Gluesync installation directory (/opt/gluesync on Linux, C:\Program Files\Gluesync on Windows) to your antivirus exclusion list.

  • Optionally exclude the Docker or Podman storage root to prevent container layer scanning.

  • See the Antivirus software section above for full details and the rationale.

Performance tuning

  • Review connection pool sizing for each agent.

  • Adjust polling intervals based on latency requirements (lower for real-time, higher for batch).

  • Verify best practices for memory management and buffer settings.

Related topics