Installations Overview

Apinizer can be installed in three different runtime environments: Kubernetes, Docker and Linux / VM. Each method has different operational cost and target audience. See the Method Selection tab below for a detailed comparison.

uyarı

Apinizer does not recommend single-server installation for production environments. Consider such a configuration only for PoC environments.

Method Selection

Two ways to run Apinizer: container or standalone.

Run every Apinizer component on your own Kubernetes cluster or Docker host via the official apinizercloud images, or on bare-metal Linux via signed tarball installers. Same builds, same versions, your infrastructure.

On the container side, Kubernetes is the choice for production, HA, and auto-scaling; Docker suits mid-scale deployments and quick PoCs. On the standalone side, Virtual Server installation fits regulated environments (banking, government), air-gapped networks, and scenarios that require a bundled JDK. Pick the right method by going through the decision matrix below.

Quick Decision Matrix

Scenario	Recommended Method
Kubernetes cluster ready, production, HA + auto-scaling	Kubernetes
One/few servers, container experience available, quick PoC	Docker
Regulated environment (bank/government), K8s/Docker banned or restricted	Linux / VM
Offline (air-gapped) installation	Linux / VM (offline install)
5+ Workers, distributed quota / circuit breaker	Kubernetes or Linux / VM multi-node (Cache cluster)
Developer machine, ephemeral test environment	Docker (docker-compose)

Method Comparison

Criterion	Kubernetes	Docker	Linux / VM
Operational complexity	High	Medium	Low
Learning curve	Steep	Medium	Flat
High availability (HA)	Built-in	Compose / Swarm	Manual multi-node
Auto-scaling	HPA / VPA	None	None
Zero-downtime upgrade	Rolling update	Replica-by-replica rotation	Manual + LB
Bundled JDK	No (JRE inside image)	No (JRE inside image)	Yes (Temurin 25 packaged)
Air-gapped support	Helm + private registry	Private registry	Native (offline tarball)
Native cert requirements	TLS Ingress / cert-manager	Reverse proxy / self-terminate	Reverse proxy / self-terminate
Encrypted configuration	K8s Secret	Docker Secret / env	Jasypt master key + ENC(...)
Hardware requirement (prod)	3+ node cluster, 8+ vCPU/node	1-3 hosts, 4+ vCPU/host	1-3 hosts, 4+ vCPU/host
Cloud provider integration	EKS / AKS / GKE / OpenShift	On cloud VMs	On cloud VMs

When Not to Choose

Do not choose Kubernetes if

• You are setting up a single-server PoC — K8s overhead is disproportionate at that scale.
• Your team has no Kubernetes experience and no time to learn it.
• A regulated environment forbids Kubernetes (some banking/government environments).

Do not choose Docker if

• You will run 5+ Worker replicas in production — managing the Hazelcast cluster becomes heavy in Compose.
• You need automatic failover (Docker alone does not provide HA orchestration).
• Container runtimes are banned by corporate policy.

Do not choose Linux / VM if

• You want multi-node dynamic scaling — adding/removing nodes by hand is friction-heavy.
• The container ecosystem (CI/CD image registry, scan pipeline) is already established — VM integration is extra work.

Shared Prerequisite — MongoDB

uyarı

MongoDB installation is mandatory — you must have a running MongoDB instance before bringing up Apinizer. Manager metadata, deployed proxy snapshots, Integration scheduler queue, and audit records all live on MongoDB. This dependency does not change whichever runtime (Kubernetes, Docker, or Virtual Server) you pick.

A replica set is recommended for production; a single node is only suitable for PoC / development. For installation steps → continue at MongoDB Installation.

Pre-Installation Decisions

Decisions to be made before installing Apinizer are grouped below by category. Each section shows the critical decision points and recommendations for that topic.

Installation & Infrastructure

Will applications such as Kubernetes Cluster and MongoDB that Apinizer needs be installed or are they already available and will be used?

Our Recommendations

• Using these components if they are already available in your organization
• Preparing them by your team if installation will be done
• Having installation done by the Apinizer team if installation will be done
• If installation will be done by the Apinizer team, the relevant servers must have access to the accesses in the Access and Port Requirements for Installation page

If installation will be done, will your organization's employees do it or will servers be allocated to the Apinizer team?

This decision determines who will manage the installation process.

If installation will be done by the Apinizer team, will internet access on the servers be restricted or full?

Internet access status affects the installation method (online/offline).

Network & Security

Is there a product other than WAF and firewall that controls the network where Apinizer will be installed and performs security hardening?

bilgi

Since such a product can also block internal traffic of the cluster where Apinizer is located, it is important to report this if such a product exists, as it will speed up the search for solutions in possible problems. This information can be obtained from your organization's Network and Security Unit employees.

Is there a usage in the 10.244.x.x block in the network where Apinizer will be installed?

uyarı

If it is used, this information should be obtained from your organization's network team, as Apinizer installation will need to be installed on another block.

Port & DNS

Which ports should Apinizer publish on the servers where it is located?

Our Recommendations

• From the 30000-32767 range, 32080 for Manager, 30080 or 30090 for worker
• At ports to be set under the management of your organization's DevOps Team (again from the same range or using nginx ingress)

Will the DNSs that Apinizer will access be automatically resolved on the servers where Apinizer will be located? If not, are these IP-host definitions ready as available?

Our Recommendations

• Setting servers to automatically resolve these addresses, as they can change even very rarely
• Preparing hostname-IP pairs as a list to be added to Apinizer

Will Apinizer interface and workers be used via DNS? If yes, what will the DNSs be?

Our Recommendations

• Addresses such as apimanagement.organization.com and api.organization.com

SSL & NAT

Where will SSL termination be done?

Our Recommendations

• On your organization's firewall
• In the application where your organization performs DNS routing and load balancing
• On Apinizer worker applications

If Apinizer will be used outside your organization, which IP will it exit from? Have the necessary (NAT) operations been performed for Apinizer servers to exit from this address?

Our Recommendations

• Not changing your organization's existing exit, Apinizer also exiting from this address

Worker & Management

How will Apinizer's worker application (Core and RAM usage, JVM parameters) be configured?

Our Recommendations

• Dividing your existing license into two or three and entering appropriate JVM parameters and distributing to multiple containers
• With different settings according to your organization's applied policy

How will Kubernetes systems where Apinizer will be installed be managed?

Our Recommendations

• From the Apinizer interface
• With methods belonging to your organization

Logging & Backup

Where should traffic logs be written?

Our Recommendations

• To one of the servers allocated with Elasticsearch that Apinizer will install
• To another application set up by your organization

If traffic logs are in Elasticsearch managed by Apinizer, how will the backup of data here be taken?

Our Recommendations

• Your organization's System team employees will backup the disk where logs are written as is
• Your organization's System team employees will backup the server where logs are located as is
• Requesting to be sent to a specific address on a specific server with snapshot policy and logs will be backed up here

Are there sensitive information that should not appear in traffic logs? If yes, what are they? In which parts of the message should they not appear?

Our Recommendations

• Organization policy can be requested from your organization's Information Security Team
• Key values containing personal data such as Tckn and TcKimlikNo

Where should application and token retrieval logs (if settings are active) be written?

Our Recommendations

• To Apinizer's configuration database
• To another application set up by your organization

How will the growth of logs to be stored in the database be kept under control?

Our Recommendations

• These logs will be deleted at certain intervals
• Disk will be expanded as it fills up

User Management & Support

Will the admin user account created with the first installation be used for the Apinizer interface? If yes, who will use it?

Our Recommendations

• Your Integration Unit employees using Apinizer if available, creating their own authorized user accounts for people who will use it, disabling the admin account
• The admin user being used by a single person responsible for Apinizer, defining new users for other people who will use it

Will user management accessing the Apinizer interface be managed entirely from Apinizer or will password verification be done with LDAP/Active Directory?

Our Recommendations

• Users should always be defined in Apinizer, but password verification should be done by defining your organization's LDAP/AD application to Apinizer and opening a user or service account with permission to verify users who will connect
• Users being managed entirely from Apinizer

How will the Apinizer support team provide support to your team using Apinizer, to the Apinizer application, and optionally to the servers where Apinizer is installed?

Our Recommendations

• Defining VPN and giving permission only to Apinizer servers and Apinizer interface
• With applications that provide remote access such as Anydesk, Team Viewer
• With meeting applications that allow remote access such as Zoom, Cisco Webex, Microsoft Teams, Skype
• With meeting applications such as Whereby, Turkcell Bip Meet
• By mail, phone and physically as a guest to the organization when necessary

Access & Ports

Apinizer Port Requirements

Default ports for Apinizer modules grouped by installation method. All defaults can be changed — but related network permissions must be reviewed after any change.

Kubernetes

Internet Access Requirements (Kubernetes)

Kubernetes cluster bootstrap needs the following addresses reachable (package repositories, container image registries, CNI components):

• archive.ubuntu.com / cdn.redhat.com
• *.docker.com
• *.docker.io
• *.k8s.io
• *.amazonaws.com (please refer to Kubernetes documentation for the reason)
• *.mongodb.org
• artifacts.elastic.co

bilgi

Docker and Virtual Server installations do not need this list. Docker only needs reachability to hub.docker.com (or your private corporate registry), and Virtual Server typically needs no internet access thanks to the offline tarball support.

bilgi

Note: These port requirements have been validated for Kubernetes 1.31.0 and Flannel 0.27.4. Ports may differ for other Kubernetes/CNI versions.

Apinizer Services (NodePort)

Kubernetes uses the 30000-32767 NodePort range for external access by default.

Service	NodePort	Protocol	Description
Manager	32080	HTTP	Apinizer Manager UI / REST API
Worker	30080 or 30090	HTTP	Gateway HTTP listener
API Portal	32081	HTTP	Developer portal
MongoDB	25080	TCP	MongoDB access (replica-set internode)
Elasticsearch HTTP	9200	HTTP	Elasticsearch REST
Elasticsearch Transport	9300	TCP	Elasticsearch cluster communication

Kubernetes Cluster Internal Ports

Ports required for Kubernetes cluster components to talk to each other. These must be open in the indicated direction for the cluster to function correctly.

Worker Node → Master Node

Port	Protocol	Description	Required
6443	HTTPS	Kubernetes API Server	Yes
10250	HTTPS	Kubelet API	Yes
10259	HTTPS	Kube-scheduler	Yes
10257	HTTPS	Kube-controller-manager	Yes
2379-2380	TCP	etcd client/server	Yes
8472	UDP	Flannel VXLAN	Yes
51820/51821	UDP	Flannel Wireguard	Optional

Master Node → Worker Node

Port	Protocol	Description	Required
10250	HTTPS	Kubelet API	Yes
30000-32767	TCP/UDP	NodePort Services	Yes
8472	UDP	Flannel VXLAN	Yes
51820/51821	UDP	Flannel Wireguard	Optional

Master Node ↔ Master Node

Port	Protocol	Description	Required
6443	HTTPS	Kubernetes API Server	Yes
2379-2380	TCP	etcd client/server	Yes
10250	HTTPS	Kubelet API	Yes
10259	HTTPS	Kube-scheduler	Yes
10257	HTTPS	Kube-controller-manager	Yes
8472	UDP	Flannel VXLAN	Yes

High Availability (HA) — Load Balancer

For HA Cluster installations the Load Balancer VIP must be reachable on port 6443:

• VIP → Master Node 1:6443
• VIP → Master Node 2:6443
• VIP → Master Node 3:6443

HAProxy configuration examples are available for the Load Balancer.

uyarı

Add-ons like Ingress Controller, Metrics Server, Rancher, Lens, and managed Kubernetes (EKS/AKS/GKE/OpenShift) may require additional ports; check them separately.

Docker

bilgi

The table below lists in-container application ports. Expose them on the host via docker run -p <host-port>:<container-port> or the ports: block in docker-compose.yml.

Apinizer Services

Module	Container Port	Protocol	Description
Manager	8080	HTTP	Manager UI / REST API
Worker (HTTP)	8091	HTTP	Gateway HTTP listener
Worker (HTTPS)	8443	HTTPS	Gateway HTTPS listener (when enabled in the Environment)
Cache (Hazelcast)	5701	TCP	Hazelcast wire protocol (Workers connect here)
Cache (REST)	8090	HTTP	Cache REST API
Integration	8092	HTTP	Quartz scheduler REST (called from Manager)
API Portal	8080	HTTP	Developer portal (must run on a host other than Manager)

Database

Service	Port	Protocol	Description
MongoDB	25080	TCP	MongoDB connection
Elasticsearch HTTP	9200	HTTP	(Optional — for traffic logs)
Elasticsearch Transport	9300	TCP	(Optional — cluster communication)

uyarı

Manager and Portal cannot both run on the same host on port 8080 — one needs a different host port mapping (e.g. -p 8081:8080).

Linux / VM

In Linux/VM installations each module runs from its own standalone package; ports are listened on directly on the host (no NAT/proxy).

Apinizer Services

Module	Default Port	Protocol	Configuration key
Manager	8080	HTTP	SERVER_PORT
Worker (HTTP)	8091	HTTP	WORKER_HTTP_PORT
Worker (HTTPS)	8443	HTTPS	WORKER_HTTPS_PORT (when Environment HTTPS is enabled)
Cache (Hazelcast)	5701	TCP	hazelcast.network.port
Cache (REST)	8090	HTTP	SERVER_PORT (cache module)
Integration	8092	HTTP	SERVER_PORT (integration module)
API Portal	8080	HTTP	SERVER_PORT (portal module — different host than Manager)

Database

Service	Port	Protocol	Description
MongoDB	25080	TCP	MongoDB connection (Manager + Integration)
Elasticsearch HTTP	9200	HTTP	(Optional — for traffic logs)
Elasticsearch Transport	9300	TCP	(Optional — cluster communication)

Host limits

Worker needs raised file descriptor limits for high throughput. In /etc/security/limits.d/apinizer-worker.conf:

apinizer soft nofile 1048576
apinizer hard nofile 1048576

uyarı

systemd hardening (ProtectSystem=strict, PrivateTmp=true) is mandatory — removing them stops Undertow from writing /tmp/undertow-docbase.* and the service crashes.

Installation Topologies

uyarı

Apinizer does not recommend single-server installation for production environments. Consider such a configuration only for PoC environments.

uyarı

Do not use Test/PoC installations for load testing! To evaluate the right configuration for load testing, please refer to our Benchmark Results page or contact us.

Topologies by Installation Method

Each runtime has its own server count, scaling model, and HA strategy. Pick your runtime from the tabs below; every tab shows detailed server lists for PoC / Professional / High Available levels.

Kubernetes

PoC / Test

Server	Operating System	CPU	RAM	Disk	Installations
Server 1	Ubuntu 24.04 LTS / RHEL 9.x	8 Core	16 GB	200 GB	Kubernetes Control-Plane, Elasticsearch (Master+Data), MongoDB Single Instance
Server 2	Ubuntu 24.04 LTS / RHEL 9.x	8 Core	12 GB	80 GB	Kubernetes Worker

Professional

Server	Operating System	CPU	RAM	Disk	Installations
Server 1	Ubuntu 24.04 LTS / RHEL 9.x	8 Core	32 GB	1 TB	Kubernetes Control-Plane, Elasticsearch (Master+Data), MongoDB Single Instance
Server 2	Ubuntu 24.04 LTS / RHEL 9.x	10 Core	12 GB	80 GB	Kubernetes Worker
Server 3	Ubuntu 24.04 LTS / RHEL 9.x	10 Core	12 GB	80 GB	Kubernetes Worker

High Available

Kubernetes Control-Plane Nodes

Server	Operating System	CPU	RAM	Disk	Installations
Server 1	Ubuntu 24.04 LTS / RHEL 9.x	4 Core	4 GB	80 GB	Kubernetes Control-Plane
Server 2	Ubuntu 24.04 LTS / RHEL 9.x	4 Core	4 GB	80 GB	Kubernetes Control-Plane
Server 3	Ubuntu 24.04 LTS / RHEL 9.x	4 Core	4 GB	80 GB	Kubernetes Control-Plane

Kubernetes Worker Nodes

Server	Operating System	CPU	RAM	Disk	Installations
Server 4	Ubuntu 24.04 LTS / RHEL 9.x	12 Core	16 GB	80 GB	Kubernetes Worker
Server 5	Ubuntu 24.04 LTS / RHEL 9.x	12 Core	16 GB	80 GB	Kubernetes Worker
Server 6	Ubuntu 24.04 LTS / RHEL 9.x	12 Core	16 GB	80 GB	Kubernetes Worker

MongoDB Replica Set Nodes

Server	Operating System	CPU	RAM	Disk	Installations
Server 7	Ubuntu 24.04 LTS / RHEL 9.x	4 Core	12 GB	200 GB	MongoDB Replica Set Node 1
Server 8	Ubuntu 24.04 LTS / RHEL 9.x	4 Core	12 GB	200 GB	MongoDB Replica Set Node 2
Server 9	Ubuntu 24.04 LTS / RHEL 9.x	4 Core	12 GB	200 GB	MongoDB Replica Set Node 3

Elasticsearch Cluster Nodes

Server	Operating System	CPU	RAM	Disk	Installations
Server 10	Ubuntu 24.04 LTS / RHEL 9.x	8 Core	64 GB	2 TB	Elasticsearch Cluster Node 1 (Master+Data)
Server 11	Ubuntu 24.04 LTS / RHEL 9.x	8 Core	64 GB	2 TB	Elasticsearch Cluster Node 2 (Master+Data)
Server 12	Ubuntu 24.04 LTS / RHEL 9.x	8 Core	64 GB	2 TB	Elasticsearch Cluster Node 3 (Master+Data)

Docker

bilgi

Docker topologies run all Apinizer modules from official apinizercloud/<module> images. For single-host use docker-compose.yml; multi-host uses Docker Swarm or manual orchestration.

PoC / Test

Server	Operating System	CPU	RAM	Disk	Installations
Server 1	Ubuntu 24.04 LTS / RHEL 9.x	8 Core	16 GB	200 GB	Docker Compose: MongoDB + Manager + Worker + Cache + Integration + Portal

Professional

Server	Operating System	CPU	RAM	Disk	Installations
Server 1	Ubuntu 24.04 LTS / RHEL 9.x	8 Core	16 GB	500 GB	MongoDB + Manager + Cache + Integration + Portal (Docker containers)
Server 2	Ubuntu 24.04 LTS / RHEL 9.x	8 Core	12 GB	80 GB	Worker container
Server 3	Ubuntu 24.04 LTS / RHEL 9.x	8 Core	12 GB	80 GB	Worker container

High Available

Manager + Portal Hosts (active-passive or behind LB)

Server	Operating System	CPU	RAM	Disk	Installations
Server 1	Ubuntu 24.04 LTS / RHEL 9.x	8 Core	16 GB	200 GB	Manager + Portal containers
Server 2	Ubuntu 24.04 LTS / RHEL 9.x	8 Core	16 GB	200 GB	Manager + Portal containers (replica)

Worker Hosts (behind LB)

Server	Operating System	CPU	RAM	Disk	Installations
Server 3	Ubuntu 24.04 LTS / RHEL 9.x	12 Core	16 GB	80 GB	Worker container
Server 4	Ubuntu 24.04 LTS / RHEL 9.x	12 Core	16 GB	80 GB	Worker container
Server 5	Ubuntu 24.04 LTS / RHEL 9.x	12 Core	16 GB	80 GB	Worker container

Cache Cluster Hosts (Hazelcast TCP/IP discovery)

Server	Operating System	CPU	RAM	Disk	Installations
Server 6	Ubuntu 24.04 LTS / RHEL 9.x	4 Core	8 GB	80 GB	Cache container
Server 7	Ubuntu 24.04 LTS / RHEL 9.x	4 Core	8 GB	80 GB	Cache container
Server 8	Ubuntu 24.04 LTS / RHEL 9.x	4 Core	8 GB	80 GB	Cache container

MongoDB Replica Set Hosts

Server	Operating System	CPU	RAM	Disk	Installations
Server 9	Ubuntu 24.04 LTS / RHEL 9.x	4 Core	12 GB	500 GB	MongoDB Replica Set Node 1
Server 10	Ubuntu 24.04 LTS / RHEL 9.x	4 Core	12 GB	500 GB	MongoDB Replica Set Node 2
Server 11	Ubuntu 24.04 LTS / RHEL 9.x	4 Core	12 GB	500 GB	MongoDB Replica Set Node 3

Linux / VM

bilgi

Linux/VM topologies use standalone packages bundled with OpenJDK 25 — no host Java required. Sensitive configuration values are encrypted in place via a Jasypt master key.

PoC / Test

Server	Operating System	CPU	RAM	Disk	Installations
Server 1	Ubuntu 24.04 LTS / RHEL 9.x	8 Core	16 GB	200 GB	MongoDB + Manager + Worker + Cache + Integration + Portal (all on one host)

Professional

Server	Operating System	CPU	RAM	Disk	Installations
Server 1	Ubuntu 24.04 LTS / RHEL 9.x	8 Core	16 GB	200 GB	Manager + Cache + Integration + Portal standalone packages
Server 2	Ubuntu 24.04 LTS / RHEL 9.x	10 Core	12 GB	80 GB	Worker standalone package
Server 3	Ubuntu 24.04 LTS / RHEL 9.x	10 Core	12 GB	80 GB	Worker standalone package
Server 4	Ubuntu 24.04 LTS / RHEL 9.x	4 Core	16 GB	500 GB	MongoDB Single Instance

High Available

Manager + Portal VMs (active-passive or behind LB)

Server	Operating System	CPU	RAM	Disk	Installations
VM 1	Ubuntu 24.04 LTS / RHEL 9.x	8 Core	16 GB	200 GB	Manager + Portal standalone
VM 2	Ubuntu 24.04 LTS / RHEL 9.x	8 Core	16 GB	200 GB	Manager + Portal standalone (replica)

Worker VMs (behind LB)

Server	Operating System	CPU	RAM	Disk	Installations
VM 3	Ubuntu 24.04 LTS / RHEL 9.x	12 Core	16 GB	80 GB	Worker standalone
VM 4	Ubuntu 24.04 LTS / RHEL 9.x	12 Core	16 GB	80 GB	Worker standalone
VM 5	Ubuntu 24.04 LTS / RHEL 9.x	12 Core	16 GB	80 GB	Worker standalone

Cache Cluster VMs (Hazelcast TCP/IP discovery)

Server	Operating System	CPU	RAM	Disk	Installations
VM 6	Ubuntu 24.04 LTS / RHEL 9.x	4 Core	8 GB	80 GB	Cache standalone
VM 7	Ubuntu 24.04 LTS / RHEL 9.x	4 Core	8 GB	80 GB	Cache standalone
VM 8	Ubuntu 24.04 LTS / RHEL 9.x	4 Core	8 GB	80 GB	Cache standalone

MongoDB Replica Set VMs

Server	Operating System	CPU	RAM	Disk	Installations
VM 9	Ubuntu 24.04 LTS / RHEL 9.x	4 Core	12 GB	500 GB	MongoDB Replica Set Node 1
VM 10	Ubuntu 24.04 LTS / RHEL 9.x	4 Core	12 GB	500 GB	MongoDB Replica Set Node 2
VM 11	Ubuntu 24.04 LTS / RHEL 9.x	4 Core	12 GB	500 GB	MongoDB Replica Set Node 3

Topology Selection Guide

Scenario	PoC / Test	Professional	High Available
Proof of Concept projects	Yes	-	-
Development and test environments	Yes	-	-
Low-traffic applications	Yes	-	-
Quick setup requirements	Yes	-	-
Limited resources	Yes	-	-
Mid-scale production environments	-	Yes	-
Medium-traffic applications	-	Yes	-
Basic HA requirements	-	Yes	-
Budget optimization	-	Yes	-
Critical production environments	-	-	Yes
High-traffic applications	-	-	Yes
99.9%+ HA requirements	-	-	Yes
Data security and replication	-	-	Yes
Global distribution	-	-	Yes

Scaling Recommendations

• Vertical scaling: CPU/RAM increase, disk capacity increase, single-server performance.
• Horizontal scaling: increase Worker node count, expand MongoDB replica set, expand Elasticsearch cluster.