All-in-One Docker Installation

This page covers installation of Apinizer's core modules on Docker in a single place. Order matters: first Manager (registration + Environment), then Worker, then Cache. Integration is only needed if you use task-flow scheduler. API Portal has its own page — install it after the Manager.

Overview

Apinizer is published as official images on Docker Hub. The images are built on Eclipse Temurin 25; the entrypoint reads the container's memory limit and automatically picks the right heap / direct-memory / metaspace values.

bilgi

Sensitive values (MongoDB URI, secrets) are passed as plaintext environment variables in the Docker flow — the container does not run the boot-time ENC(...) decryption used by the Linux package. Use Docker Secrets (Compose / Swarm) or Kubernetes Secrets to inject them safely.

If you want to bring everything up with a single docker-compose.yml:

Docker Compose (All-in-One)

Reference example that brings up all 5 modules in a single docker-compose.yml

Recommended Install Order

1. MongoDB (must be installed first — see MongoDB Installation)
2. API Manager → validates MongoDB connection, runs Mongock migrations
3. Worker → fetches its Environment from Manager
4. Cache → Hazelcast cluster (if Worker uses quota/OIDC/CB)
5. Integration (optional) → starts the Quartz scheduler, registers with Manager
6. API Portal → connects to the Manager REST API, serves the developer portal

Upgrade

For upgrading on Docker: Upgrading on Docker

Image Convention

All images are published under apinizercloud/<module>:

Module	Image
API Manager	apinizercloud/apimanager
API Portal	apinizercloud/apiportal
Worker	apinizercloud/worker
Cache	apinizercloud/cache
Integration	apinizercloud/integration

Tag convention

Tag	Channel	Note
<MAJOR.MINOR.PATCH> (e.g. 2026.04.5)	release	Promoted to production
<MAJOR.MINOR.PATCH>.qa.<N> (e.g. 2026.04.5.qa.1)	QA	Pre-release, may change
<MAJOR.MINOR.PATCH>-rc.<id>	release candidate	Frozen, immutable
<MAJOR.MINOR.PATCH>-SNAPSHOT	develop	Rolling, do not use in prod

uyarı

latest is not published — always pin to an explicit version tag.

On Apple Silicon (M1/M2/M3/M4)

Images currently publish only for linux/amd64. On Apple Silicon Macs Docker Desktop shows the warning "Image may have poor performance, or fail, if run via emulation". Workaround:

• Docker Desktop → Settings → General → enable "Use Rosetta for x86_64/amd64 emulation on Apple Silicon". Apple Rosetta is much faster than QEMU.
• For production, use an x86_64 Linux host.

Shared Prerequisites

MongoDB Installation

All modules connect to the same MongoDB database

Port Requirements

Which module uses which port

1. API Manager

The Apinizer API Manager is the control plane — admin UI, REST API, MongoDB-backed configuration, proxy lifecycle and policy management. Install it first; all other modules register against it.

This guide walks through running the Apinizer API Manager Docker image on a Linux host. The image contains the application, its dependencies and an OpenJDK 25 runtime — Java is not required on the host. The image's entrypoint inspects the container memory limit at boot and selects a tier-aware heap / direct-memory / metaspace profile automatically.

bilgi

Sensitive values (MongoDB URI, secrets) are passed as plaintext environment variables in the Docker flow — the container does not run the boot-time ENC(...) decryption used by the Linux package. Use Docker secrets (Compose / Swarm) or Kubernetes Secrets to inject them safely.

Requirements

• A Linux x86-64 host with Docker Engine 24+ or Docker Desktop
• Outbound network to docker.io (or a mirror with apinizercloud/apimanager)
• A reachable MongoDB instance (replica set recommended for production)
• A free TCP port on the host to expose the Manager (default 8080)

1. Pull the image

VERSION=2026.04.5
docker pull apinizercloud/apimanager:${VERSION}

See Docker overview — tag convention.

2. Configure

Required environment variables (the container exits at startup if they are empty):

Variable	Description
SPRING_DATA_MONGODB_URI	MongoDB connection string (e.g. mongodb://user:pass@host:25080/?replicaSet=rs0&authSource=admin)
SPRING_DATA_MONGODB_DATABASE	Database name (e.g. apinizer)
SPRING_PROFILES_ACTIVE	prod (default — keep on production hosts)

Optional:

Variable	Default	Description
SERVER_PORT	8080	HTTP port inside the container
JAVA_OPTS	empty	Extra JVM flags (merged with tier defaults)
jvmOverride	false	When true, JAVA_OPTS wins over the tier-aware defaults
JHIPSTER_SLEEP	0	Pre-start delay in seconds (useful when MongoDB starts in the same compose)

3. Run the container

docker run -d \
  --name apinizer-apimanager \
  -p 8080:8080 \
  --memory=4g \
  -e SPRING_DATA_MONGODB_URI='mongodb://user:pass@mongo:25080/?authSource=admin' \
  -e SPRING_DATA_MONGODB_DATABASE='apinizer' \
  -e SPRING_PROFILES_ACTIVE=prod \
  -v apinizer-apimanager-logs:/app/logs \
  --restart unless-stopped \
  apinizercloud/apimanager:${VERSION}

ipucu

The --memory=4g cap is also read by the JVM tier auto-tuner — without it the JVM sees the full host memory and may oversize the heap. Match this to the resources you actually want the Manager to consume.

4. docker-compose (recommended)

services:
  apimanager:
    image: apinizercloud/apimanager:2026.04.5
    container_name: apinizer-apimanager
    restart: unless-stopped
    mem_limit: 4g
    ports:
      - "8080:8080"
    environment:
      SPRING_PROFILES_ACTIVE: prod
      SPRING_DATA_MONGODB_DATABASE: apinizer
      JAVA_OPTS: "-XX:+ExitOnOutOfMemoryError"
    env_file:
      - ./secrets/apimanager.env       # contains SPRING_DATA_MONGODB_URI=…
    volumes:
      - apimanager-logs:/app/logs
    healthcheck:
      test: ["CMD-SHELL", "wget -qO- http://127.0.0.1:8080/management/health | grep -q '\"status\":\"UP\"'"]
      interval: 30s
      timeout: 5s
      retries: 5
      start_period: 90s

volumes:
  apimanager-logs:

Start:

docker compose up -d
docker compose logs -f apimanager

5. Verify

curl -fsS http://127.0.0.1:8080/management/health

Expected: a 200 OK response with health details. The first start runs the embedded Mongock migrations and can take 30–90 s depending on database size.

6. Operations

Action	Command
Status	docker ps --filter name=apinizer-apimanager
Logs (follow)	docker logs -f apinizer-apimanager
Restart	docker restart apinizer-apimanager
Stop	docker stop apinizer-apimanager
Shell	docker exec -it apinizer-apimanager sh

7. Networking

• Inbound: only 8080/tcp needs to be reachable by Worker/Portal nodes and admin users.
• Outbound: the Manager connects to MongoDB and any configured backend services (LDAP, OIDC, SMTP). It does not need outbound internet in steady state.
• For multi-container deployments, place all Apinizer services on the same user-defined Docker network and reference them by service name.

8. Resources

Workload	mem_limit
Smoke test / single tenant	2 GB
Production (≤ 200 active proxies)	4 GB
Large install / many concurrent admins	6–8 GB

CPU: 2 vCPU minimum, 4 vCPU recommended.

Troubleshooting

Container exits with URI is not set or DATABASE is not set

A required env var is empty. Recreate the container with the variables populated. Watch out for shell quoting around ?replicaSet=…&authSource=… — pass via -e SPRING_DATA_MONGODB_URI="…" quoted or via an env-file.

Health endpoint returns 503 OUT_OF_SERVICE

MongoDB is unreachable. Test from inside the container:

docker exec -it apinizer-apimanager sh -lc \
  "wget -qO- $SPRING_DATA_MONGODB_URI" 2>&1 | head

Memory tier: 1GB (heap 50%…) even though the host has 32 GB

You did not pass --memory / mem_limit. The cgroup default is max and the auto-tuner falls back to total host memory. Set mem_limit to match what you want the container to use.

MongoDB connection times out

• Verify network reach: docker exec apinizer-apimanager sh -lc 'nc -zv mongo 25080'.
• Check that the URI carries the correct replicaSet= and authSource=.
• TLS to MongoDB: append &tls=true and mount the CA file.

2. API Worker

The Apinizer Worker is the gateway runtime — it terminates HTTP / HTTPS / gRPC / WebSocket requests, runs deployed proxy policy pipelines, and emits traffic logs. Install it after the Manager (so an Environment exists to register against) and the Cache (so quotas/sessions are shared).

This guide walks through running the Apinizer Worker (the API Gateway runtime) as a Docker container. The Worker terminates HTTP / HTTPS / gRPC / WebSocket requests, runs the deployed proxy policy pipelines, and emits traffic logs.

bilgi

The Worker image is built on Ubuntu noble (glibc) — not Alpine — because the brotli4j native compression library has no musl build. Do not rebuild against Alpine.

Requirements

• A Linux x86-64 host with Docker Engine 24+
• The same MongoDB instance used by the Manager
• An Environment entry registered in the Manager UI (Server Management → Environments)
• A reachable Apinizer Cache (Hazelcast cluster) if you use quotas, OIDC sessions, circuit breakers
• Free TCP ports on the host:
  • 8091/tcp — HTTP gateway listener
  • 8443/tcp — HTTPS gateway listener (when enabled in the Environment)

1. Pull the image

VERSION=2026.04.5
docker pull apinizercloud/worker:${VERSION}

2. Configure

Required:

Variable	Description
SPRING_DATA_MONGODB_URI	MongoDB connection string
SPRING_DATA_MONGODB_DATABASE	MongoDB database name
APINIZER_ENVIRONMENT_NAME	Environment name. Must exactly match an Environment in the Manager UI.
WORKER_TIMEZONE	Timezone offset for log timestamps (e.g. +03:00)

Recommended:

Variable	Default	Description
JAVA_OPTS	empty	"-server -XX:MaxRAMPercentage=75.0 -Dhttp.maxConnections=4096 -Dlog4j.formatMsgNoLookups=true" for production

Optional (Undertow / gateway tuning):

Variable	Default	Description
tuneWorkerThreads	1024	XNIO worker pool
tuneWorkerMaxThreads	4096	Hard cap on the worker pool
tuneIoThreads	4	XNIO I/O selectors (set to vCPU count)
tuneBufferSize	16384	Read/write buffer size (bytes)
tuneDirectBuffers	true	Off-heap buffers (less GC pressure)
tuneBacklog	10000	Kernel TCP listen backlog
APINIZER_WORKER_NODE_IP	auto	Override the reported node IP (multi-NIC hosts)

3. Run the container

docker run -d \
  --name apinizer-worker \
  -p 8091:8091 \
  -p 8443:8443 \
  --memory=8g \
  --cpus=4 \
  -e SPRING_DATA_MONGODB_URI='mongodb://user:pass@mongo:25080/?authSource=admin' \
  -e SPRING_DATA_MONGODB_DATABASE='apinizer' \
  -e APINIZER_ENVIRONMENT_NAME='prod-dc1' \
  -e WORKER_TIMEZONE='+03:00' \
  -e JAVA_OPTS='-server -XX:MaxRAMPercentage=75.0 -Dhttp.maxConnections=4096 -Dlog4j.formatMsgNoLookups=true' \
  -v apinizer-worker-logs:/app/logs \
  --restart unless-stopped \
  --ulimit nofile=1048576:1048576 \
  apinizercloud/worker:${VERSION}

ipucu

The Worker is throughput-sensitive: it benefits from --ulimit nofile=1048576:1048576 for high concurrent connection counts.

4. docker-compose

services:
  worker:
    image: apinizercloud/worker:2026.04.5
    container_name: apinizer-worker
    restart: unless-stopped
    mem_limit: 8g
    cpus: 4
    ports:
      - "8091:8091"
      - "8443:8443"
    environment:
      SPRING_DATA_MONGODB_DATABASE: apinizer
      APINIZER_ENVIRONMENT_NAME: prod-dc1
      WORKER_TIMEZONE: "+03:00"
      JAVA_OPTS: "-server -XX:MaxRAMPercentage=75.0 -Dhttp.maxConnections=4096 -Dlog4j.formatMsgNoLookups=true"
      tuneWorkerThreads: "1024"
      tuneIoThreads: "4"
    env_file:
      - ./secrets/worker.env
    ulimits:
      nofile:
        soft: 1048576
        hard: 1048576
    volumes:
      - worker-logs:/app/logs
    healthcheck:
      test: ["CMD-SHELL", "wget -qO- http://127.0.0.1:8091/server-status | grep -q OK || exit 1"]
      interval: 30s
      timeout: 5s
      retries: 5
      start_period: 60s

volumes:
  worker-logs:

5. Verify

curl -fsS http://127.0.0.1:8091/server-status

Send a test request through a deployed proxy:

curl -fsS http://127.0.0.1:8091/echo -H 'X-Trace: 1'

Expected boot logs:

ApiGateway standalone=true (env: prod-dc1)
HTTP listener bound: 0.0.0.0:8091
HTTPS listener bound: 0.0.0.0:8443    (only if Environment enables HTTPS)
Loaded N proxies for environment prod-dc1

6. Operations

Action	Command
Status	docker ps --filter name=apinizer-worker
Logs	docker logs -f apinizer-worker
Restart	docker restart apinizer-worker
Stop (drain)	docker stop -t 60 apinizer-worker

uyarı

Use a generous stop timeout (docker stop -t 60) so in-flight HTTP / gRPC / WebSocket requests can drain. Without -t, Docker kills with SIGTERM after 10 s.

7. Networking

Inbound

Port	Purpose
8091	HTTP gateway
8443	HTTPS gateway

Outbound

• MongoDB (proxy config + traffic log writes)
• Cache cluster on 5701/tcp (Hazelcast wire) and 8090/tcp (REST), when quotas/OIDC/CB are used
• Each backend service every deployed proxy is wired to

8. Multi-Worker (horizontal scale)

Run the same image with the same APINIZER_ENVIRONMENT_NAME on each replica. Quota counters, OIDC sessions and circuit-breaker state are shared through the Apinizer Cache (Hazelcast). Without a shared Cache, each Worker has its own counters.

9. Resources

Workload	mem_limit	cpus
Smoke / staging (<200 rps)	2 GB	2
Production (1–3 krps per Worker)	4–6 GB	4
High throughput (5+ krps)	8 GB	4–8

Always load-test on the target hardware before changing JVM flags.

Troubleshooting

APINIZER_ENVIRONMENT_NAME mismatch → container starts but proxies don't load

If the name does not match an Environment in the Manager UI exactly (case sensitive), no proxy snapshot is fetched and every request returns 404. Fix: correct the env var or create the Environment.

UnsatisfiedLinkError: brotli

You are running a custom build of the Worker on Alpine. Switch back to the official apinizercloud/worker image (Ubuntu noble base).

EMFILE: too many open files

Add --ulimit nofile=1048576:1048576 to docker run. Also check that /etc/security/limits.conf / the host's LimitNOFILE allows it.

3. API Cache

The Apinizer Cache is a Hazelcast data grid that backs quotas, OIDC sessions, circuit-breaker state and client-flow banners. Install it after the Manager and before the Worker so Workers can join it on first boot.

This guide walks through running the Apinizer Cache (the Hazelcast data grid that backs quotas, OIDC sessions, circuit-breaker state and client-flow banners) as a Docker container. The Cache writes durable counter snapshots to MongoDB via Hazelcast MapStore and serves reads/writes to the Worker on a Spring Boot HTTP port.

bilgi

Standalone mode is auto-detected: when the container does not have a Kubernetes service-account namespace file, the Cache switches Hazelcast discovery from the Kubernetes plug-in to TCP/IP.

Requirements

• A Linux x86-64 host with Docker Engine 24+
• A reachable Apinizer Manager-managed MongoDB instance
• Free TCP ports on the host:
  • 5701/tcp — Hazelcast wire protocol (member-to-member and Worker → Cache)
  • 8090/tcp — Spring Boot HTTP (Worker → Cache REST)
• For multi-node clusters: bidirectional reachability between Cache nodes on 5701/tcp

1. Pull the image

VERSION=2026.04.5
docker pull apinizercloud/cache:${VERSION}

2. Configure

Required:

Variable	Description
SPRING_DATA_MONGODB_URI	MongoDB connection string
SPRING_DATA_MONGODB_DATABASE	MongoDB database (same as Manager/Worker)
CACHE_QUOTA_TIMEZONE	Quota window timezone offset (e.g. +03:00). Must match Worker and Manager.

Recommended:

Variable	Default	Description
HAZELCAST_CLUSTER_NAME	apnz-hz-cluster	Logical cluster name. Override only if you run multiple independent Apinizer installs on the same LAN. Mismatch with Worker → silent split-brain.
APINIZER_CACHE_CLUSTER_MEMBERS	empty	Comma-separated peer list for multi-node TCP/IP discovery
SERVER_PORT	8090	Spring Boot HTTP port

3. Single-node Cache

docker run -d \
  --name apinizer-cache \
  -p 5701:5701 \
  -p 8090:8090 \
  --memory=4g \
  -e SPRING_DATA_MONGODB_URI='mongodb://user:pass@mongo:25080/?authSource=admin' \
  -e SPRING_DATA_MONGODB_DATABASE='apinizer' \
  -e CACHE_QUOTA_TIMEZONE='+03:00' \
  -v apinizer-cache-logs:/app/logs \
  --restart unless-stopped \
  apinizercloud/cache:${VERSION}

Expected boot log:

Cache running in STANDALONE mode (cluster: apnz-hz-cluster)
Standalone Hazelcast cluster members: 127.0.0.1
Members {size:1, ver:1} [ Member [127.0.0.1]:5701 - ... ]

4. Multi-node Cache cluster

Each node needs the same peer list and the same cluster name.

Compose (single-host, three replicas — for testing)

services:
  cache-1:
    image: apinizercloud/cache:2026.04.5
    container_name: apinizer-cache-1
    networks:
      apinizer:
        ipv4_address: 172.30.0.11
    environment: &cache-env
      SPRING_DATA_MONGODB_DATABASE: apinizer
      CACHE_QUOTA_TIMEZONE: "+03:00"
      HAZELCAST_CLUSTER_NAME: apnz-hz-cluster
      APINIZER_CACHE_CLUSTER_MEMBERS: 172.30.0.11,172.30.0.12,172.30.0.13
    env_file: [./secrets/cache.env]
    mem_limit: 4g
    restart: unless-stopped

  cache-2:
    image: apinizercloud/cache:2026.04.5
    container_name: apinizer-cache-2
    networks:
      apinizer:
        ipv4_address: 172.30.0.12
    environment: *cache-env
    env_file: [./secrets/cache.env]
    mem_limit: 4g
    restart: unless-stopped

  cache-3:
    image: apinizercloud/cache:2026.04.5
    container_name: apinizer-cache-3
    networks:
      apinizer:
        ipv4_address: 172.30.0.13
    environment: *cache-env
    env_file: [./secrets/cache.env]
    mem_limit: 4g
    restart: unless-stopped

networks:
  apinizer:
    driver: bridge
    ipam:
      config:
        - subnet: 172.30.0.0/24

Multi-host

On each host, set APINIZER_CACHE_CLUSTER_MEMBERS to the same comma-separated list of host IPs.

ipucu

TCP/IP discovery is symmetric — if host B does not list host A, B will not accept A as a member even though A reaches B. Distribute the same peer list to every node.

5. Verify

REST health:

curl -fsS http://127.0.0.1:8090/management/health

Hazelcast members:

docker logs apinizer-cache | grep -E 'Members \{'

Expected on a 3-node cluster:

Members {size:3, ver:3} [
    Member [172.30.0.11]:5701 - ...
    Member [172.30.0.12]:5701 - ...
    Member [172.30.0.13]:5701 - ...
]

If only one member is listed, check firewall rules on 5701/tcp and that every node lists the same peers.

6. Wire Workers to the Cache

Each Worker must:

• Use the same Hazelcast cluster name
• Reach every Cache node on 5701/tcp
• See the same MongoDB database

7. Operations

Action	Command
Status	docker ps --filter name=apinizer-cache
Logs	docker logs -f apinizer-cache
Restart	docker restart apinizer-cache
Stop (drain)	docker stop -t 30 apinizer-cache

8. Resources

Workload	mem_limit
Single tenant, low traffic	2 GB
Production (1 Worker, ≤1 krps)	4 GB
Production cluster (3+ Workers)	4–6 GB per node

Do not run the Cache with less than 2 GB of mem_limit in production.

Troubleshooting

Members {size:1} on every node even though the peer list is correct

• Check HAZELCAST_CLUSTER_NAME matches on every node (case sensitive).
• Verify 5701/tcp is reachable both ways: nc -zv <peer-ip> 5701 from each container.
• On multi-host setups behind NAT (cloud), TCP/IP discovery requires routable, symmetric addresses.

Quotas reset unexpectedly

The CACHE_QUOTA_TIMEZONE value differs from the Worker / Manager timezone. They must all agree.

4. API Integration (Optional)

The Apinizer Integration is a Quartz-based task-flow scheduler. Install it only if you use task flows / connector pipelines from the Manager UI. Skip this tab otherwise.

This guide walks through running the Apinizer Integration tier — the Quartz scheduler that runs task flows registered by the Manager — as a Docker container. The Integration container reads task-flow / connector definitions from MongoDB and stores its Quartz job state in schedule_integration_* collections.

bilgi

The Integration is stateless beyond MongoDB: every Quartz lock, trigger, calendar and job-status row lives in MongoDB. Restart the container as often as you like — running jobs may be interrupted, but no scheduling state is lost.

Requirements

• A Linux x86-64 host with Docker Engine 24+
• The same MongoDB instance used by the Manager
• A free TCP port on the host (default 8092) — restricted to the Manager's IP/CIDR

1. Pull the image

VERSION=2026.04.5
docker pull apinizercloud/integration:${VERSION}

2. Configure

Required:

Variable	Description
SPRING_DATA_MONGODB_URI	MongoDB connection string — same instance the Manager uses
SPRING_DATA_MONGODB_DATABASE	MongoDB database name — must match the Manager database
INTEGRATION_TIMEZONE	IANA zone id (e.g. Europe/Istanbul). Must match Manager and Worker timezone.

Optional:

Variable	Default	Description
SERVER_PORT	8092	Spring Boot HTTP port
SPRING_PROFILES_ACTIVE	prod	Keep on production hosts
JAVA_OPTS	empty	Extra JVM flags
LOG_LEVEL	INFO	Application log level

3. Run the container

docker run -d \
  --name apinizer-integration \
  -p 8092:8092 \
  --memory=2g \
  --stop-timeout=120 \
  -e SPRING_DATA_MONGODB_URI='mongodb://user:pass@mongo:25080/?authSource=admin' \
  -e SPRING_DATA_MONGODB_DATABASE='apinizer' \
  -e INTEGRATION_TIMEZONE='Europe/Istanbul' \
  -e SPRING_PROFILES_ACTIVE=prod \
  -v apinizer-integration-logs:/app/logs \
  --restart unless-stopped \
  apinizercloud/integration:${VERSION}

uyarı

Use --stop-timeout=120 (or stop_grace_period: 120s in compose). Quartz is configured with waitForJobsToCompleteOnShutdown=true, so a SIGTERM triggers a clean drain. Without the extended grace, Docker kills with SIGKILL after 10 s and in-flight task flows are cut mid-step.

Expected boot log:

Integration timezone set to: Europe/Istanbul
Initializing Custom MongoDB Job Store
Quartz Scheduler Prod Environment Setup started
MongoDB connection established for Quartz Job Store
Tomcat started on port 8092 (http)

4. docker-compose

services:
  integration:
    image: apinizercloud/integration:2026.04.5
    container_name: apinizer-integration
    restart: unless-stopped
    mem_limit: 2g
    stop_grace_period: 120s
    ports:
      - "8092:8092"
    environment:
      SPRING_DATA_MONGODB_DATABASE: apinizer
      INTEGRATION_TIMEZONE: Europe/Istanbul
      SPRING_PROFILES_ACTIVE: prod
    env_file:
      - ./secrets/integration.env
    volumes:
      - integration-logs:/app/logs
    healthcheck:
      test: ["CMD-SHELL", "wget -qO- http://127.0.0.1:8092/management/health | grep -q '\"status\":\"UP\"'"]
      interval: 30s
      timeout: 5s
      retries: 5
      start_period: 60s

volumes:
  integration-logs:

5. Multi-node / HA

Multiple Integration containers can share the same MongoDB database — they form a clustered Quartz scheduler automatically. Each instance:

• Auto-generates its org.quartz.scheduler.instanceId
• Locks triggers via schedule_integration_locks so the same job never fires on two nodes at once
• Recovers misfired jobs on startup

ipucu

Run at least two Integration containers when you have time-critical scheduled flows.

6. Wire the Manager to the Integration

In the Manager UI (Admin → Integration Servers) add each Integration container's hostname/IP and the HTTP port (8092). The Manager pushes job register/unregister and cache-refresh events via REST.

7. Verify

curl -fsS http://127.0.0.1:8092/management/health

Check the cluster picture from MongoDB:

use apinizer
db.schedule_integration_scheduler_state.find().pretty()

Each Integration node should have an entry with a recent last_checkin_time.

8. Operations

Action	Command
Status	docker ps --filter name=apinizer-integration
Logs	docker logs -f apinizer-integration
Restart (drain Quartz)	docker restart -t 120 apinizer-integration
Stop (drain Quartz)	docker stop -t 120 apinizer-integration

9. Resources

Workload	mem_limit
Few flows, light cadence	1 GB
Production (typical install)	2 GB
Heavy / many concurrent flows	4 GB

Troubleshooting

Quartz job didn't fire at the expected time

• Check INTEGRATION_TIMEZONE against the cron expression in the Manager.
• Multiple Integration nodes with mismatched timezones cause inconsistent fires.

Container exits with Locked by another scheduler after a hard kill

The previous container was SIGKILLed mid-trigger. The new container's lock-recovery sweep clears the stale row on startup; wait one clusterCheckin cycle (default 7.5 s) if needed.

Manager UI shows Integration as offline

The Manager cannot reach http://<integration-host>:8092/. Verify the host/port in Manager UI, firewall, and that the Integration container has finished its boot sequence.