Gateway Settings
This page contains the advanced configuration to make the Gateway run at peak performance. For basic Gateway setup, refer to the installation page matching your installation type (Kubernetes / Docker / Virtual Server). The settings here are optional; defaults are sufficient for most installations, but reviewing them for production environments is recommended for performance tuning.
The settings on this page are exposed in the Apinizer Manager UI under Server Management → Gateway Runtimes form fields. Values changed in the form take effect on the Gateway pods/containers after a redeploy.
Additional Variables
Default and optional variables and their values to be run in the pod are defined.
Basic Settings
| Field | Description |
|---|---|
| Count (Count) | The number of Gateway engines corresponds to the "replicas" value in Kubernetes deployment. Specifies the number of Pods that will be created in the Kubernetes Cluster to be created. |
| CPU | The maximum number of CPU cores the pod will use. |
| Memory (Memory) | The maximum memory value the pod will use. |
| Memory Unit (Memory Unit) | The unit of the value required for memory is selected; MB, GB. |
Recommended Values (by Benchmark Tier):
| Tier | CPU | Memory Size | Usage Purpose |
|---|---|---|---|
| W1 | 1 | 2 GB | Test / PoC |
| W2 | 2 | 2 GB | Small production |
| W4 | 4 | 4 GB | Standard production |
| W8 | 8 | 8 GB | High-volume production |
JVM memory and GC settings are automatically configured by the entrypoint based on container resource limits. Heap is allocated at 60% for W1/W2 and 65% for W4/W8. No manual -Xmx/-Xms parameters are needed. For detailed benchmark data and capacity guidance, see the Capacity Planning page.
Service Access Information
- HTTP Enabled (HTTP Enabled): Comes selected by default
- HTTPS Enabled (HTTPS Enabled): This option is also selected if HTTPS is desired, in this case the necessary files for encryption must be uploaded
- mTLS: Can only be selected when HTTPS setting is open since it runs on HTTPS protocol
Keystore and Truststore: When HTTPS protocol is selected, keystore and truststore files can be uploaded in JKS or PFX format.
Service Ports: A service port in the range 30080-32767 is entered. The service will be created as NodePort in Kubernetes.
Gateway Management API Service:
- Create HTTP service for API Gateway Management API access (
httpServiceForManagementAPIEnabled): When enabled, creates a separate HTTP service for Gateway Management API access. This service is used by Apinizer Management Console to communicate with Gateway pods for configuration updates. - Create HTTPS service for API Gateway Management API access (
httpsServiceForManagementAPIEnabled): When enabled, creates a separate HTTPS service for Gateway Management API access. Requires keystore and truststore files to be uploaded. Use this option when secure communication between Management Console and Gateway pods is required.
Management API Services:
These services are separate from the main HTTP/HTTPS services used for API Proxy traffic. They are specifically used for:
- Configuration updates from Management Console to Gateway pods
- Health checks and monitoring
- Management operations
When these services are enabled, you should configure the corresponding URLs in the Management API Access Endpoints section.
gRPC Protocol Settings
If Gateway Management API will communicate with gateway pods over HTTPS:
- The Create HTTPS service for API Gateway Management API access option is selected
- Keystore and truststore files can be uploaded in JKS or PFX format
- Gateway Server Access URL is entered
Example: https://worker-http-service.prod.svc.cluster.local:8443
gRPC Tuning Parameters:
| Variable | Description | Default |
|---|---|---|
tuneGrpcKeepAliveTime | gRPC keep-alive time (seconds) | 120 |
tuneGrpcKeepAliveTimeout | gRPC keep-alive timeout (seconds) | 20 |
tuneGrpcMaxMessageSize | gRPC maximum message size (bytes) | 4194304 (4MB) |
tuneGrpcMaxHeaderListSize | gRPC maximum header list size (bytes) | 8192 |
tuneGrpcMaxConnectionAge | gRPC maximum connection age (seconds) | 3600 |
tuneGrpcMaxConnectionAgeGrace | gRPC maximum connection age grace period (seconds) | 30 |
tuneGrpcMaxConnectionIdle | gRPC maximum connection idle time (seconds) | 300 |
tuneGrpcMaxInboundMessageSize | gRPC maximum inbound message size (bytes) | 4194304 (4MB) |
tuneGrpcMaxInboundMetadataSize | gRPC maximum inbound metadata size (bytes) | 8192 |
tuneGrpcHandshakeTimeout | gRPC handshake timeout (seconds) | 20 |
tuneGrpcPermitKeepAliveTime | gRPC permit keep-alive time (seconds) | 120 |
tuneGrpcThreadPoolSize | gRPC thread pool size | CPU count * 2 |
WebSocket Settings
WebSocket Tuning Parameters:
| Variable | Description | Default |
|---|---|---|
tuneWebsocketIdleTimeout | WebSocket idle timeout (seconds) | 60 |
tuneWebsocketBufferSize | WebSocket buffer size (bytes) | 65536 |
tuneWebsocketTcpNoDelay | WebSocket TCP no delay (true/false) | true |
CORS Settings
Purpose of CORS Settings:
These CORS (Cross-Origin Resource Sharing) parameters are used for requests coming for token acquisition. Policies are not added to requests coming for token acquisition from the Management Console; these settings are provided through environment configuration. These parameters are not used in normal API Proxy flow, they are only valid for token acquisition endpoints.
CORS (Cross-Origin Resource Sharing) Parameters:
| Variable | Description | Default |
|---|---|---|
tokenCorsAccessControlAllowOrigin | Access-Control-Allow-Origin header value | - |
tokenCorsAccessControlAllowCredentials | Access-Control-Allow-Credentials header value | - |
tokenCorsAccessControlAllowMethods | Access-Control-Allow-Methods header value | - |
tokenCorsAccessControlAllowHeaders | Access-Control-Allow-Headers header value | - |
tokenCorsAccessControlOrigin | Origin header value | - |
tokenCorsAccessControlRequestMethod | Access-Control-Request-Method header value | - |
tokenCorsAccessControlRequestHeaders | Access-Control-Request-Headers header value | - |
tokenCorsAccessControlExposeHeaders | Access-Control-Expose-Headers header value | - |
tokenCorsAccessControlMaxAge | Access-Control-Max-Age header value (seconds) | - |
X-Forwarded-For Settings
Purpose of X-Forwarded-For Settings:
These X-Forwarded-For parameters are used for requests coming for token acquisition. Policies are not added to requests coming for token acquisition from the Management Console; these settings are provided through environment configuration. These parameters are not used in normal API Proxy flow, they are only valid for token acquisition endpoints.
X-Forwarded-For Parameters:
| Variable | Description | Default |
|---|---|---|
tokenXForwardedForIpHeader | X-Forwarded-For IP header name | - |
tokenXForwardedForIpOrder | X-Forwarded-For IP order (FIRST/LAST) | LAST |
Security Configuration
Security configuration can be made with Additional Variables:
| Variable | Description | Default Value | Possible Values | Target Java Property |
|---|---|---|---|---|
jdkTLSVersions | Determines TLS protocol versions to be supported | TLSv1, TLSv1.1, TLSv1.2, TLSv1.3 | SSLv2Hello, SSLv3, TLSv1, TLSv1.1, TLSv1.2, TLSv1.3 | https.protocols, jdk.tls.client.protocols, jdk.tls.server.protocols |
jdkTLSDisabledAlgorithms | Determines TLS algorithms to be disabled for security reasons | RC4, DES, MD5withRSA, DH keySize < 768, EC keySize < 224, 3DES_EDE_CBC, anon, NULL | RC4, DES, MD5withRSA, DH keySize < 768, EC keySize < 224, 3DES_EDE_CBC, anon, NULL, SSLv3, TLSv1, TLSv1.1 | jdk.tls.disabledAlgorithms |
jdkCertPathDisabledAlgorithms | Determines algorithms not to be used during certificate validation | JDK default value | MD2, MD5, SHA1, RSA keySize values, DSA keySize values, EC keySize values | jdk.certpath.disabledAlgorithms |
jdkCipherSuites | Determines encryption suites to be used | JDK default value | For TLS 1.3: TLS_AES_256_GCM_SHA384, TLS_AES_128_GCM_SHA256, TLS_CHACHA20_POLY1305_SHA256; For TLS 1.2: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384; Legacy: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_256_CBC_SHA | https.cipherSuites |
jdkAllowUnsafeProtocols | Determines whether unsafe protocols are allowed | false | true, false | https.protocols.allow_unsafe, jdk.tls.client.protocols.allow_unsafe |
Important Notes:
-
When Additional Variables are not set:
- For TLS Versions: "TLSv1, TLSv1.1, TLSv1.2, TLSv1.3" is used
- For TLS Disabled Algorithms: "RC4, DES, MD5withRSA, DH keySize < 768, EC keySize < 224, 3DES_EDE_CBC, anon, NULL" is used
- For other parameters: JDK default values are used
-
Security Recommendations:
- TLSv1.2 and higher versions should be used
- GCM mode encryption suites should be preferred
- Weak algorithms (RC4, DES, 3DES) should be disabled
- Key sizes should be at an adequate security level (at least 2048 bits for RSA, at least 224 bits for EC)
-
Performance Impact:
- The order of encryption suites can affect performance
- Disabling too many encryption suites may cause compatibility issues with legacy systems
Variables
Default and optional variables and their values to be run in the pod are defined.
Important Variables:
| Variable | Target Environment | Description |
|---|---|---|
JAVA_OPTS | All | Sets JVM Heap values |
WORKER_TIMEZONE | All | Sets the JVM default time zone for the Worker process. Accepts IANA zone IDs (e.g. Europe/Istanbul) or fixed offsets (e.g. +03:00). When unset, the container falls back to the system time zone (typically UTC). Affects time-based variable evaluation, scheduled limits, and any field that does not carry its own zone information. |
tuneWorkerThreads | HTTP Worker, HTTP+Websocket, Management API | Minimum Worker thread count of the server. Tier defaults: W1=128, W2=256, W4=512, W8=1536 |
tuneWorkerMaxThreads | HTTP Worker, HTTP+Websocket, Management API | Maximum Worker thread count of the server. Tier defaults: W1=256, W2=512, W4=1024, W8=3072 |
tuneBufferSize | HTTP Worker, HTTP+Websocket, Management API | Buffer area the thread will use for write operations (default: 16384 bytes) |
tuneIoThreads | HTTP Worker, HTTP+Websocket, Management API | IO Thread count. Tier defaults: W1=2, W2=4, W4=8, W8=16 |
tuneBacklog | HTTP Worker, HTTP+Websocket, Management API | Backlog value. Tier defaults: W1=2048, W2=4096, W4=8192, W8=16384 |
tuneRoutingConnectionPoolMaxConnectionPerHost | HTTP Worker, HTTP+Websocket, Management API | Maximum connections per host. Tier defaults: W1=250, W2=500, W4=1000, W8=2000 |
tuneRoutingConnectionPoolMaxConnectionTotal | HTTP Worker, HTTP+Websocket, Management API | Total maximum connections. Tier defaults: W1=500, W2=1000, W4=2000, W8=4000 |
tuneRoutingConnectionPoolMinThreadCount | HTTP Worker, HTTP+Websocket, Management API | Routing Connection Pool minimum thread count |
tuneRoutingConnectionPoolMaxThreadCount | HTTP Worker, HTTP+Websocket, Management API | Routing Connection Pool maximum thread count |
tuneElasticsearchClientIoThreadCount | HTTP Worker, HTTP+Websocket, Management API | Elasticsearch Client IO Thread count |
tuneMaxConcurrentRequest | HTTP Worker, HTTP+Websocket, Management API | Maximum concurrent request count. Tier defaults: W1=500, W2=750, W4=3000, W8=10000 |
tuneMaxQueueSize | HTTP Worker, HTTP+Websocket, Management API | Maximum queue size (default: 0) |
tuneCacheConnectionPoolMaxConnectionTotal | HTTP Worker, HTTP+Websocket, Management API | Cache Connection Pool total maximum connections (default: 2048) |
tuneApiCallConnectionPoolMaxConnectionPerHost | HTTP Worker, HTTP+Websocket, Management API | API Call Connection Pool maximum connections per host (default: 256) |
tuneApiCallConnectionPoolMaxConnectionTotal | HTTP Worker, HTTP+Websocket, Management API | API Call Connection Pool total maximum connections (default: 4096) |
multipartConfigMaxFileSize | HTTP Worker, HTTP+Websocket, Management API | Multipart config maximum file size (default: 100MB) |
multipartConfigMaxRequestSize | HTTP Worker, HTTP+Websocket, Management API | Multipart config maximum request size (default: 100MB) |
multipartConfigFileSizeThreshold | HTTP Worker, HTTP+Websocket, Management API | Multipart config file size threshold (default: 100MB) |
defaultCharset | HTTP Worker, HTTP+Websocket, Management API | Default character set (default: UTF-8) |
deploymentTimeout | HTTP Worker, HTTP+Websocket, Management API | Deployment timeout in seconds (default: 30) |
tuneReadTimeout | HTTP Worker, HTTP+Websocket, Management API | Client data read timeout. Connection will be closed if client doesn't send data within this time (default: 30000 ms / 30 seconds) |
tuneNoRequestTimeout | HTTP Worker, HTTP+Websocket, Management API | No request after connection timeout. Connection will be closed if no request is sent after connection established (default: 60000 ms / 60 seconds) |
http2Enabled | HTTP Worker, HTTP+Websocket, Management API | Enable HTTP/2 protocol (default: false) |
environmentClusterName | HTTP Worker, HTTP+Websocket, Management API | Environment cluster name |
tuneAsyncExecutorCorePoolSize | HTTP Worker, HTTP+Websocket, Management API | Async executor core pool size (default: tuneWorkerThreads) |
tuneAsyncExecutorMaxPoolSize | HTTP Worker, HTTP+Websocket, Management API | Async executor maximum pool size (default: tuneWorkerMaxThreads) |
tuneAsyncExecutorQueueCapacity | HTTP Worker, HTTP+Websocket, Management API | Async executor queue capacity (default: tuneMaxQueueSize > 0 ? tuneMaxQueueSize : 1000) |
METRICS_ENABLED | HTTP Worker, HTTP+Websocket, Management API | Whether metric collection feature is enabled (default: false) |
logLevel | All | Application log level (ERROR, WARNING, INFO, DEBUG, TRACE, OFF) |
tuneMaxDecompressedBodySize | HTTP Worker, HTTP+Websocket, Management API | Maximum size (in bytes) of a compressed (gzip, deflate, brotli, zstd) request or response body after decompression. Protects against compression bomb attacks (default: 2147483648 / 2 GB) |
Compression Bomb Protection:
The Gateway enforces a maximum size limit when decompressing compressed request and response bodies to protect against compression bomb attacks. A small compressed body can consume gigabytes of memory when decompressed — the tuneMaxDecompressedBodySize parameter prevents this.
The default value is set to 2 GB and covers the vast majority of current usage scenarios. You can lower this value according to your security requirements (e.g., 50 MB = 52428800, 100 MB = 104857600). The value is specified in bytes.
Setting this limit too low may cause legitimate large requests or responses to be rejected. Determine an appropriate value by considering the typical request sizes in your environment.
Asynchronous Operations Thread Pool:
The Rest API Policy and Script Policy use a centralized thread pool for asynchronous operations which is configured in ManagementConfig. This improves thread management and optimizes resource usage. Asynchronous operations performed in environments are managed by this separate thread pool, which can be configured with specific parameters to ensure optimal performance and resource allocation.
Usage Scenarios:
- Rest API Policy: Asynchronous HTTP calls to external services
- Script Policy: Asynchronous script executions that don't block the main request thread
- Logging Operations: Asynchronous log writing operations
- Traffic Mirroring: Asynchronous mirroring of requests to secondary endpoints
Configuration Guidelines:
tuneAsyncExecutorCorePoolSize: Minimum number of threads kept alive in the pool (default: same astuneWorkerThreads)tuneAsyncExecutorMaxPoolSize: Maximum number of threads that can be created (default: same astuneWorkerMaxThreads)tuneAsyncExecutorQueueCapacity: Maximum number of tasks that can wait in the queue before new threads are created (default:tuneMaxQueueSizeif > 0, otherwise 1000)
Thread Pool Sizing:
The async executor thread pool is separate from the main worker thread pool. Ensure that the total thread count (worker threads + async executor threads) does not exceed your system's capacity. Consider CPU cores and memory when configuring these values.
Benchmark-Verified Tier Thread and Connection Values:
The following values are optimal settings validated through wrk2 load tests. The entrypoint applies these as defaults for each tier; fine-tune as needed for your production workload.
| Tier | CPU | tuneIoThreads | tuneWorkerThreads | tuneWorkerMaxThreads | tuneBacklog | tuneMaxConcurrentRequest |
|---|---|---|---|---|---|---|
| W1 | 1 | 2 | 128 | 256 | 2048 | 500 |
| W2 | 2 | 4 | 256 | 512 | 4096 | 750 |
| W4 | 4 | 8 | 512 | 1024 | 8192 | 3000 |
| W8 | 8 | 16 | 1536 | 3072 | 16384 | 10000 |
Routing Connection Pool (tuneRoutingConnectionPoolMaxConnectionPerHost / tuneRoutingConnectionPoolMaxConnectionTotal):
| Tier | Max Conn/Host | Max Conn Total | ES Max Conn/Host |
|---|---|---|---|
| W1 | 250 | 500 | 8 |
| W2 | 500 | 1,000 | 16 |
| W4 | 1,000 | 2,000 | 32 |
| W8 | 2,000 | 4,000 | 128 |
Java Options Warning:
Apinizer's entrypoint automatically configures JVM heap values based on tier and container memory limit:
- W1 / W2 (2 GB):
MaxRAMPercentage=60— heap ~1.2 GB - W4 (4 GB):
MaxRAMPercentage=65— heap ~2.6 GB - W8 (8 GB):
MaxRAMPercentage=65— heap ~5.2 GB
UseContainerSupport is enabled by default. When -Xmx / -Xms values are provided, automatic sizing is disabled — use these only if you have a specific requirement. G1GC is used as the garbage collector.
Configurations
After Gateway installation is complete, the General Settings, Gateway Environments, Log Connector, Backup, and other configurations that need to be made through the Manager UI are runtime-independent. Whichever runtime you have chosen (Kubernetes, Docker, or Virtual Server), the steps below apply.
All of these steps are done in the Manager UI (left menu → System Settings). There is no runtime difference. The Manager must already be running and you must be logged in with the admin user.
General Settings
By going to System Settings → General Settings page, here;
- Whether a value will be added to the end of the addresses you define to the relevant Worker environments when serving the services you will serve through the system,
- Whether you will manage the Kubernetes environment where Apinizer is located through Apinizer (only applies to Kubernetes installations),
- Whether logs of error messages will be sent to connected connectors even if log settings are closed,
- Settings related to login and session duration for Management Console interface,
- Number of rollback points to be kept in each proxy,
- Applications where application logs and token logs will be kept/sent
changes can be made. Appropriate definitions for your organization should be made here.
Click here for detailed information about this page.
Gateway Environments Page Settings
At least one environment must be created and published on the System Settings → Gateways page.
By giving an appropriate environment name, settings are entered to containers with resources suitable for your license and server quantity. On Kubernetes installations this environment name will also be the Kubernetes namespace where the applications in the relevant environment will run. Then, Connector definitions are made to the environments where you want to write logs, enabling the environments to write logs.
When Kubernetes is managed by Apinizer
Click here for detailed information about Gateway Runtimes page and Distributed Cache page.
Here, on the Gateway Runtimes page opened with the new environment option, general settings such as which namespace you will create the environment in, which address you will open it from, which connectors you will connect, and the resources and JVM parameters of worker applications are set and the environment is published. Cache server configuration is done separately on the Distributed Cache page.
When Kubernetes is NOT managed by Apinizer (or Docker / Virtual Server install)
When creating a Gateway Runtime, you can define existing Kubernetes / Docker / Virtual Server Worker definitions to the Apinizer platform by selecting the Remote Gateway option. For detailed information, see the Gateway Runtimes page.
For detailed manual Kubernetes deploy steps (rolebinding, deployment, service, secret copy), see the Kubernetes Manifest > Worker Setup and Configuration > Installation page.
Adding Log Connectors to Environments
At least one Log connector must be connected to the created environments.
Click here for detailed information about adding Log Connector to environments.
After completing the above steps, go to the Server Management section on API Manager again and update the Environment you have defined as published.
Backup Management / Backup Settings
Backup of the database where Apinizer configuration data and, if you have set them on the General Settings page, log and token records are kept can be done by extracting a dump file on the relevant (if there are more than one, the one specified in this setting) server.
It is recommended that this file be backed up to a secure server by your organization's system team employees in any case.
Click here for detailed information about this page.
Other Settings
Please change the password of the "admin" user account you logged into Apinizer Management Console at the first login from the Change Password page under the quick menu at the top right and note it securely. Click here for detailed information about the Users page where user management is done.
Many features you will use in Apinizer write their logs to the database where configuration data is kept. If these information are logs that are not necessary according to your organization's policies, click here for detailed information about what these data are and how this growth will be kept under control.
If you are using Elasticsearch managed by Apinizer for Apinizer traffic logs and prefer that its backup be done by taking snapshots at certain intervals, click here to perform these operations in detail.
It is strongly recommended that DNS routing be done to the ports where Worker environments are opened in Apinizer installation and the servers they run on. For this, your organization's employees should be informed about which server and ports Apinizer is opened from and which DNSs should be used to access these addresses.
If your organization is part of the kamunet network and Apinizer will directly access the kamunet network, Apinizer servers' exits should be able to exit as if they were your kamunet IP. This operation called NAT'ing needs to be set up by your organization's firewall administrators.
If your organization wants to use the KPS (Identity Sharing System) services offered by the General Directorate of Population and Citizenship Affairs through Apinizer, your organization's kps information should be entered into the management console from the KPS Setting page.
Congratulations! If you have successfully reached this point, it means that Apinizer installation and settings are completed.