Bring Your Own Cloud

For customers with strict security and data protection requirements, Traversal offers a BYOC (Bring Your Own Cloud) deployment option on AWS. Deployed inside of your cloud account, this option provides a private, fully segregated, single-tenant, and shared-nothing deployment of Traversal. All connections to your private data sources occur over private, secure, and always-encrypted network paths.

​

Architecture

Traversal BYOC is deployed, fully-managed, and operated by Traversal inside of a separate, dedicated cloud account that you own; for example, a separate AWS account part of your AWS organization. This separation helps protect the security of your systems and applications while providing Traversal with the access necessary to deliver and maintain a highly-available service. Access to your private data sources and environments can be made through the Traversal Connector architecture (pictured above) and through dedicated, secure, PrivateLink service endpoints to cross the VPC boundary. With the exception of reporting system and usage telemetry to Traversal, Traversal BYOC deployments do not interact with Traversal’s SaaS/cloud deployments. No customer data ever leaves the BYOC environment’s boundary.

​

Networking

The entirety of the Traversal BYOC environment is deployed in a dedicated VPC, with all relevant infrastructure spread across multiple availability zones and hosted in private subnets. Traversal requires a dedicated /20 Class A CIDR block for its VPC, with at least three /22 private subnets — one per distinct availability zone — for its deployment and operations. Public subnets, when used, are sized as /24 and fit within the remaining /22 of address space.

​

Compute

All compute powering Traversal’s services, data stores, data pipelines, agentic workflows, and applications, runs on cloud instances (in AWS, EKS-on-EC2) and managed cloud services inside of the provided, dedicated cloud account.

​

AI Models and Inference

Traversal uses frontier AI models (LLMs) to power its AI SRE agent. At your discretion, those models can be cloud-hosted (from LLM providers directly), routed through a private gateway, or fully hosted in your cloud environment (in AWS, with Bedrock).

​

Access control

Access to your BYOC deployment of Traversal by your users is always secured and controlled by Single Sign-on (SSO) with your Identity Provider. Deployment and management of infrastructure, as well as operational access by Traversal, is performed through a cross-account IAM AssumeRole, scoped to the dedicated AWS account that hosts your Traversal BYOC deployment. Access by Traversal operators for maintenance and support is made through a secure and audited Tailscale-based VPN, restricted to authorized Traversal personnel only, and always secured by SSO with two-factor authentication.

​

Telemetry

Two categories of telemetry data leave your BYOC deployment: system telemetry, used to monitor and support your deployment, and usage telemetry, used for product analytics, customer success, and billing. They’re handled differently.

​

System telemetry

By default, system telemetry (metrics, logs, and traces about your Traversal deployment) is sent to Traversal’s centralized observability solution outside of your environment. If needed, some telemetry attributes can be redacted or filtered before leaving your BYOC deployment. If your requirements call for it, you can instead opt to keep system telemetry and monitoring entirely within your environment. In that configuration, alerts derived from that telemetry must still be allowed to egress to Traversal’s on-call solution (PagerDuty), so Traversal operators can be notified of and respond to issues affecting your deployment.

​

Usage telemetry

Regardless of your system telemetry configuration, Traversal always collects the following usage telemetry, which leaves your environment:

• Client-side user analytics — events generated by user interactions in the web app
• Server-side user analytics — user events and feedback signals, such as thumbs up/down reactions
• Usage data — investigations initiated, follow-ups initiated, and activity of Traversal workers

All telemetry data is always sent securely over HTTPS to authenticated endpoints.

​

Data security

All data stored by Traversal in databases, network-attached storage volumes, and cloud storage buckets remains in your AWS account dedicated for Traversal’s BYOC deployment. Data is always encrypted at rest and in-transit by best-in-class encryption from your cloud provider (AES-256 and TLS1.3).

​

Network security

Within the Traversal platform, all service-to-service traffic is authenticated and encrypted in-transit with mTLS/TLS1.3. Connections to your private data sources and environments are always made through dedicated, private, secure, and encrypted network paths (PrivateLink) with the Traversal Connector.

​

Ingress

By default, no inbound connections to your Traversal BYOC deployment can be made from the public internet. Your access and connection to Traversal is routed through your private network. The following inbound connections (through secure PrivateLink service endpoints) must be established and allowed:

• From your users to Traversal’s web application and API;
• From your Traversal Connector to the Edge Controller in your Traversal BYOC deployment;
• If deployed, from your Traversal Processor to your Traversal BYOC deployment’s data ingest endpoint.

If you use the Traversal Slack integration, inbound webhook connections from Slack to the Traversal API in your BYOC deployment must be allowed. This is typically https://slack.<customer>.traversal.com.

​

Egress

To ensure the proper operation of your Traversal BYOC deployment, the following outbound connections must be allowed:

• To login.traversal.com and *.auth0.com for authentication;
• To telemetry.traversal.com for reporting usage telemetry, and — unless you’ve opted to keep system telemetry within your environment — system telemetry, to Traversal;
• To *.rudderstack.com for user telemetry;
• To *.pagerduty.com for monitoring and alerting;
• To api.sendgrid.com for transactional email delivery;
• To *.tailscale.com for Traversal’s Tailscale-based operational VPN (required for upgrades, maintenance, and support);
• To *.okta.com for authentication of Traversal operators with our identity provider;
• To *.letsencrypt.org for issuance of SSL/TLS certificates;
• To *.github.com and *.githubusercontent.com for pulling Traversal platform repositories (required for deployment and upgrades);
• To *.ghcr.io and *.docker.io (and *.cloudflare.docker.com for Docker Hub image layers) for pulling third-party Docker images;
• To *.pypi.org and files.pythonhosted.org for pulling Python dependencies;
• If configuring integrations with any third-party vendor, to their endpoint domains:
  • To *.slack.com for the Traversal Slack app
  • To api.anthropic.com and/or api.openai.com for access to our LLM providers if you’re not using Bedrock

Additionally, you must ensure that the following domains and endpoints are reachable by your end users:

• Your Traversal BYOC deployment at <customer>.traversal.com and api.<customer>.traversal.com;
• login.traversal.com and *.auth0.com for authentication;
• Our user telemetry data processors:
  • *.rudderstack.com
  • *.ingest.sentry.io

​

Deployment

To deploy Traversal BYOC, after establishing your agreement with Traversal and reviewing the responsibility matrix below, you must: Traversal then proceeds with the deployment of its platform and provides you with an access endpoint URL – typically https://<customer>.traversal.com. Following this initial deployment, and depending on the needs of your environment, you will:

​

Operations

Traversal BYOC deployments are fully managed and operated by Traversal, and providing the same high-availability guarantees as our SaaS offering. Experienced Traversal operators continuously monitor, tune, and deploy updates to your Traversal BYOC deployment to ensure the highest quality of service for Traversal users.

​

Responsibility matrix