Edge Cluster Deployment
Edge cluster deployment allows you to deliver and secure your application traffic through Traceable’s global edge network. When an edge cluster is provisioned, Traceable inspects, routes, and protects your application traffic in real time while applying your configured security policies. In both cases, Traceable continues to enforce your security policies and route validated traffic to your origin. The deployment process is essentially about gathering configuration details from you. Once these details are submitted, Traceable provisions the cluster and assigns a unique subdomain for secure traffic routing.
What will you learn in this topic?
By the end of this topic, you will be able to:
Interpret Traceable’s edge deployment models and traffic flow.
Choose the deployment type that best fits your environment.
Prepare routing, network, and TLS prerequisites.
Navigate to the Edge Cluster section and start a deployment.
Configure general and service-level settings.
Submit your configuration for provisioning.
Track deployment progress using lifecycle states.
Deployment models
Traceable Edge supports two methods for sending traffic to the Traceable WAAP edge. Choose the model that best matches your current setup.
CDN/Gateway ahead of Traceable WAAP Your CDN, for example, CloudFront, Cloudflare, or gateway, remains the primary entry point. You configure it to forward traffic to your Traceable-assigned subdomain. Traceable’s WAAP inspects traffic, applies policy, and only validated traffic is forwarded to your origin. Best if you already rely on a CDN/gateway for caching, performance, or DDoS protection.
DNS-based traffic steering (direct to Traceable) You update DNS, so your public domain CNAME points to the Traceable-assigned subdomain. Requests are routed directly to Traceable WAAP, inspected, and/or policy-enforced, and then forwarded to your origin. Best if you want Traceable to be the primary entry point and security layer.
How it works (traffic flow)
A client (browser, API, bot) requests your public domain, for example, customer.com.
Depending on your model:
CDN/Gateway model: client → CDN/Gateway → Traceable WAAP
DNS model: client → (CNAME) → Traceable WAAP
Traceable WAAP enforces your security policies, for example, WAF, API protection, bot controls, L7 DDoS.
Only validated traffic is forwarded to your origin, for example, real-customer.com.
Before you begin
Before you proceed to create your first edge cluster, make a note of the following:
Domain and routing
DNS model — Configure DNS with a CNAME pointing to the Traceable-assigned subdomain (provided during deployment).
CDN/Gateway model — Configure your CDN or gateway to forward traffic to the Traceable-assigned subdomain.
Secure network configuration
Restrict your origin to accept traffic only from Traceable WAAP egress.
Allowlist Traceable AWS subnets on the origin.
Block or restrict direct internet access to the origin, where applicable.
TLS configuration
Upload TLS certificates if you plan to terminate HTTPS at the edge. For more information, see Manage TLS Certificates.
Additional requirements for managed deployment (AWS)
Infrastructure is deployed within your AWS environment.
TLS certificates must be available in AWS Certificate Manager (ACM).
Certificates must be in the same AWS region as the edge cluster.
Provide certificate ARNs and related details during setup.
Required information
Public domain(s), for example, app.customer.com.
Origin hostname or IP address and port.
TLS certificate and private key (for HTTPS).
Health-check path (if enabling origin health checks).
Steps to configure
When you create a new edge cluster, you configure it in two main sections:
General Settings — Defines the scope of the cluster, environment, and AWS regions.
Service Settings — Defines domains, certificates, origin servers, health checks, and advanced traffic handling.
Each section contains required and optional fields. The following tables describe the fields, their meaning, and default values.
Step 1 — Navigate to the edge cluster
Navigate to Settings → Edge Cluster.
Click Add New Cluster.
Step 2 — Configure general settings
In the New Edge Cluster slide-out panel, to complete the following steps, refer to the table below:
Field
Description
Default Value
Cluster Name
Descriptive label for the cluster, for example, customer_portal_prod.
—
Deployment Type
Where the edge infrastructure will run
Hosted
Environment
Traceable environment, such as Production, Staging, or Development.
—
Primary AWS Region
AWS region from which your application traffic will be delivered. Choose the region closest to your users for the lowest latency
—
Secondary AWS Region (Optional)
Backup AWS region for failover. The traffic is automatically routed to this region if the primary region is unavailable.
—
Idle Timeout (s)
The time a connection can remain idle before closing.
60
Max Connection Duration (s)
Maximum lifetime of a connection.
3600
Max Header Count
Maximum number of HTTP headers per request.
100
Max Requests per Connection
Requests allowed on a single keep-alive connection.
1000
Request Header Timeout (s)
Max time to receive headers.
2
Header Case Insensitivity
Treats HTTP headers as case-insensitive. Set to false if you require strict case sensitivity.
Enabled
General settings define the cluster's overall scope, identity, environment, and regions, as well as connection behavior defaults, such as timeouts and retry limits. These values shape the cluster's operation at a foundational level.
Step 3 — Configure services
Each cluster includes one or more services. Services define how a domain is secured and routed through Traceable. At the beginning, provide the Service Name, then configure Domain(s) and Origin Server(s).
Domain(s)
The following table displays the domain configuration options:
Field
Description
Default Value
Domain(s)
Domain to be delivered and secured, for example, app.example.com must be valid.
—
Protocol
HTTP or HTTPS.
HTTP
Port
Port used by the domain.
80 (HTTP), 443 (HTTPS)
Certificate Name
TLS certificate used for HTTPS. Displays certificates uploaded for the selected domain and region(s).
—
Enable Redirection
Select this if you wish to redirect the HTTP traffic to HTTPS
Off
Origin server(s)
Origin servers are the backends of your applications to which Traceable forwards traffic. The following table displays the origin server configuration options, which tell Traceable where to send requests and how to connect to your app:
Field
Description
Default Value
IP Address or Hostname
Address of your backend origin server.
—
Port
Port on which the origin listens.
—
Origin Type
Either IP or Hostname. Must be consistent across all origins.
—
Protocol
Protocol between Traceable and the origin (HTTP or HTTPS).
HTTP
Health check (Optional — all fields required if one is set)
Health checks allow Traceable to automatically verify that your origin servers are available and responding as expected before routing traffic to them. The following table displays the health check configuration options:
Field
Description
Default Value
Health Check Path
Path used for health checks, for example, /health.
—
Healthy Threshold
Number of consecutive successes required.
3
Unhealthy Threshold
Number of consecutive failures required.
3
Timeout (s)
Maximum time to wait for a health check response.
5
Interval (s)
Interval between health checks.
30
Success Codes
List of HTTP code ranges.
-
Advanced configurations
Advanced configurations let you fine‑tune connection handling and performance parameters beyond the basic service setup. These values control limits such as pending requests, TCP connections, and probe timings. Adjust them if you have specialized traffic patterns or scaling requirements; otherwise, defaults are typically sufficient. The following table displays the advanced configuration options:
Field
Description
Default Value
HTTP Max Requests
Maximum number of active requests to a destination.
5000
Max Pending HTTP Requests
Maximum number of queued requests.
2048
Max TCP Connections
Maximum simultaneous TCP connections.
1024
Retry Timeout (s)
Wait time before retrying a failed connection.
5
Max Probes
Maximum probes allowed.
5
Probe Interval (s)
Interval between probes.
30
Request Timeout (s)
Max time to process a request.
30
Retry Attempts
Number of times retries are attempted
2
TCP Connection Timeout (ms)
Max time to establish TCP connection.
200
TCP Keepalive Time (s)
TCP keep-alive time in seconds.
300
TCP Idle Timeout (s)
Max idle time before closing TCP connection.
3600
Step 4 — Submit deployment
Review your configuration.
Click Submit to request provisioning of the cluster.
Provisioning can take several hours.
Deployment states update automatically in the UI.
Deployment states
When you submit or modify an edge cluster deployment, it goes through a series of states. These states represent the lifecycle of your deployment request and determine who controls the next action: you or Traceable.
Deployment states are important because:
They give you visibility into where your request currently stands.
They ensure safe handoff between your actions (submitting, editing, canceling) and Traceable’s actions (provisioning, validating, approving).
They help you understand when you can make changes and when you must wait for Traceable to process your request.
They provide a clear resolution path if something is blocked or requires additional input.
There are three workflows that follow this state model:
Deployment creation — First-time creation of an edge cluster.
Deployment change — Making configuration changes to an existing cluster.
Deployment removal — Decommissioning or stopping a cluster.
Each workflow moves through similar states: Requested → In Progress → Blocked → Done.
This section describes the states visible in the user interface and the actions you can take at each step.
States and actions
This section lists each deployment state, who can trigger it, and the available actions. Use this as a reference to understand what you can do at each stage of the deployment lifecycle.
The Who Can Trigger column clarifies control of the state:
User — You can move the deployment into this state.
Traceable → User — Traceable places the deployment into this state, and then control passes back to you (for example, when a deployment is blocked and needs your changes).
Traceable — Only Traceable can act at that stage (for example, moving a request to In Progress or Done).
State
Workflow(s)
Who can trigger
Description and actions available
Deployment Requested
Creation
User
Initial state after submitting a new deployment. While in this state, you can:
• Edit the configuration
• Put the deployment On Hold
On Hold
Creation, Removal
User
Suspends the request without deleting the configuration. From here you can: /
• Resume by moving back to Requested
• Permanently delete the configuration
Deployment Blocked
Creation
Traceable → User
Indicates that additional input is required. Traceable adds a comment explaining the issue. You must edit and resubmit the configuration.
Deployment Change Requested
Change
User
Created when you edit an already deployed cluster. You can cancel before Traceable picks it up.
Deployment Change Blocked
Change
Traceable → User
Indicates that a change could not be applied. You must review comments, fix the configuration, and resubmit.
Deployment Removal Requested
Removal
User
Requests the removal of an active cluster. You can cancel before Traceable picks it up.
Deployment Removal Blocked
Removal
Traceable → User
Indicates that removal could not proceed due to missing or invalid details. You must resolve the issue before removal continues.
How transitions work
User control — You can edit, put on hold, or cancel a deployment while it is in the Requested or On Hold state. Once Traceable picks it up and the state changes to In Progress, you can only view the configuration.
Traceable control — Traceable moves deployments into In Progress, Blocked, or Done. When a deployment is blocked, it returns to your control, and you must edit and resubmit the configuration.
Examples
Blocked — If you submit a cluster with missing certificate details, the deployment will move to Blocked, and you will see a comment explaining what needs to be fixed.
On Hold — If you start creating a deployment but want to pause before Traceable provisions it, you can place it On Hold instead of deleting it.
Change Requested — If you edit an active cluster to update a domain or certificate, it enters Deployment Change Requested until Traceable processes the update.
Last updated
Was this helpful?