FAQ

• General

  Expand all

  Can STACKIT Application Load Balancer run in networks without internet connection?

  No, STACKIT Application Load Balancer instances require network connectivity to the load balancer control plane via public endpoints.

• Configuration

  Expand all

  Can I use a load balancing method other than Maglev?

  No, Maglev is the only supported load balancing method for STACKIT Application Load Balancer.

  Can I add an external service or a service from another project as a target?

  Yes, you need to set the disableTargetSecurityGroupAssignment option. You can find more details for target security groups in “basic concepts of the ALB”.

  Can I configure multiple listeners or ports?

  Yes, STACKIT Application Load Balancer supports multiple HTTP and HTTPS listeners on one assigned IP address.

  Can I use another load balancer in my project as a target?

  No, this is not supported due to internal design.

  Can targets in one target pool use different ports?

  No, all targets in a pool must use the same port.

• Observability

  Expand all

  Is there logging and metrics for load balancers?

  Yes, log streaming is fully functional and supported for both the STACKIT Application Load Balancer (ALB) and the STACKIT Network Load Balancer (NLB). Read the Observability documentation to learn more.

  What types of logs can I expect to see from my load balancer?

  Standard outputs consist primarily of underlying Envoy proxy system logs. These include if envoy just started, if it stopped and if its healthy.

  Do you support logs for the Application Load Balancer firewall?

  Yes we do but for that, observability needs to be enabled first.

  Are logs generated specifically when an Application Load Balancer firewall rule is triggered?

  Yes. When an ALB Web Application Firewall (ALB WAF) reference is set on your listener, logs are dispatched every single time an enabled rule or log only rule is triggered by incoming traffic.

  Does the credentials reference lock me into using STACKIT Observability?

  No, there is absolutely no platform vendor lock-in. While the documentation deployment examples use STACKIT Observability profiles to highlight the native cross platform support, the underlying architecture relies on standard basic authentication. You can provide credentials and a custom PushURL for any target telemetry backend that accepts basic authentication, such as open-source Grafana Loki for logs or Prometheus for metrics instances.

  Do you provide some kind of dashboard for metrics?

  Yes, when setting up STACKIT Observability, you receive a Grafana Dashboard which you can directly access with your Project in the Portal.

  Where do I find the Observability push URLs and credentials for my ALB?

  The ALB observability block on the Application Load Balancer stores two things per stream (logs and metrics): a pushUrl and a credentialsRef. Both come from an existing STACKIT Observability instance, not from the ALB itself.

  Push URL patterns

  The pushUrl for each stream follows a stable pattern per Observability instance:

  Stream	pushUrl pattern
  Logs	https://logs.<region-cluster>.argus.<region>.stackit.cloud/instances/<instance-id>/loki/api/v1/push
  Metrics	https://push.metrics.<region-cluster>.argus.<region>.stackit.cloud/instances/<instance-id>/api/v1/receive

  <region-cluster> and <region> are provisioned per Observability instance (for example, eu01). Always copy the concrete URL from the Observability instance rather than composing it by hand — the exact host prefix can vary per instance and region.

  To copy the concrete URLs for your instance, open the Observability instance detail page in the STACKIT Portal, or query the instance via the Observability API. The full walkthrough is in Locating your identifiers and Endpoint URLs.

  Credentials

  The ALB does not create Observability credentials — it references a technical credential that already exists on the Observability instance. You can create the credential using any of these tools, they are equivalent:

  • STACKIT Portal: Observability → your instance → API credentials.
  • STACKIT CLI: stackit observability credentials create ....
  • STACKIT Terraform Provider: stackit_observability_credential resource.
  • Observability API: POST to the credentials endpoint of the instance.

  Whichever tool you use, the credential name you enter in credentialsRef on the ALB must match exactly the credential name that exists on the Observability instance. If the names diverge, the ALB fails to authenticate against the push endpoint.

  For step-by-step credential creation, see Obtaining Technical Credentials.

  For the full ALB request body, see the v2 API — Application Load Balancer reference.

• Web Application Firewall

  Expand all

  How do I enable the ALB WAF for one of my ALB listeners?

  Set the wafConfigName property on the listener to the name of an existing ALB WAF configuration in the same project and region. The ALB WAF configuration must exist before you can reference it. Removing the field disables ALB WAF inspection for that listener without deleting the ALB WAF configuration itself. See “ALB WAF features” for the full listener payload.

  Can I share a single ALB WAF configuration across multiple listeners or load balancers?

  Yes. An ALB WAF configuration is a project- and region-scoped object and can be referenced by any number of ALB listeners in the same project. Managed rule sets and custom rule groups can likewise be referenced by any number of ALB WAF configurations, so you can maintain one baseline policy and reuse it across environments.

  To deploy and manage identical ALB WAF configurations across different projects or regions, we recommend using Terraform. For more information, see the STACKIT Terraform Provider documentation.

  Do I have to write raw SecLang or ModSecurity directives?

  No. STACKIT exposes a structured JSON abstraction over the underlying Coraza SecLang grammar. You configure custom rules using typed fields (variable, transformations, operator, behaviour) and the engine translates them into SecLang at runtime. See “Custom rule groups” for the rule structure.

  Note that individual rules are not standalone entities and cannot be reused on their own. Rules always live inside a custom rule group, and only the custom rule group is an object that can be attached to one or more ALB WAF configurations. To share rules across configurations, group them into a custom rule group and reference that group.

  Can I disable or silence a single OWASP CRS rule without turning off the whole rule set?

  Yes. Send a PATCH request to the managed rule set with a sparse body that targets the specific group ID and rule ID, and set mode to MODE_DISABLED (skip entirely) or MODE_LOG_ONLY (inspect and log but do not block). All other rules in the managed rule set remain unchanged. See “Per-rule overrides” for an example payload.

  In what order are custom rule groups and managed rule sets evaluated?

  Custom rule groups are evaluated before the managed rule set that is referenced by the same ALB WAF configuration. This lets you allow-list traffic that would otherwise be blocked by the OWASP Core Rule Set, or apply targeted virtual patches before generic detection runs. Inside a group, rules execute in the order returned by the API, and inside a rule, conditions execute top to bottom until the first match. By now there is no portal (UI) support for native actions, not wrapped into a MODE.

  What are the default quotas for ALB WAF configurations, managed rule sets, and custom rule groups?

  Each project has a default limit of 150 ALB WAF configurations, 150 managed rule sets, and 150 custom rule groups per region.

  To view your current usage, send a request to GET /v1beta/projects/{projectId}/regions/{region}/quotas. If you need a higher limit, contact STACKIT Support.

  Do I have to assign an ID to each custom rule I create?

  No. Custom rule IDs are auto-assigned by the backend from the range 1-99999 when you create a custom rule group. The generated IDs are returned on any subsequent GET of the custom rule group.

  How do I run a rule in "detection only" mode before enforcing it?

  To evaluate rules without blocking traffic, configure detection-only logging based on the rule type:

  • Managed rule sets: Send a PATCH request setting mode to MODE_LOG_ONLY. The ALB WAF evaluates the rule and writes matches to the security log without blocking requests. Once you verify the rule fits your workload, change mode back to MODE_ENABLED.
  • Custom rules: Set behaviour.action to ACTION_PASS and behaviour.log to true with a descriptive log_msg. The match is logged, but request processing continues.