Edit

Infrastructure Network

Bridge nodes are the endpoints of the Flashback Network, that give access to the different supported APIs. Her, you'll explore:

For testing purposes only, Flashback has deployed bridge nodes in the following providers and regions for testing purposes. Flashback will offer the capacity to users to deploy their own Flashback Bridge Nodes in their Cloud tenants to avoid excessive egress costs.

AI LLMs is partially supported. Later version will provide all the indicators in this page to understand how to interact with your favorite AI solutions.

What is a Bridge Node?

Definition

A Bridge Node is a Flashback-hosted (or self-hosted) endpoint that speaks a standard storage API—S3, GCS, or Azure Blob—and transparently translates requests to the underlying bucket/provider you’ve configured via your Repository policy. Each Bridge Node exposes a predictable URL so your apps can keep one client, one credential set, and route across clouds at runtime.

Endpoint pattern

Bridge Nodes follow: https://<api>-<region>-<provider>.flashback.tech where <api> is s3, gcs, or blob, and <region>/<provider> map to the target location/cloud (e.g., s3-us-east-1-aws.flashback.tech).

Why it matters

Flashback measures node health and latency so your code can pick the fastest Online Bridge Node (and fail over if it degrades), letting you enforce SLOs like “prefer sub-50 ms reads.” Latency is typically lowest when the Bridge Node is geographically close and on the same cloud as your bucket.

Observability

Minute-level per-node stats are exposed via GET /stats/nodes/minute (optionally filtered by bucketId) so you can drive routing decisions and dashboards. The bucket view also surfaces Online/Disconnected/Offline and HeadBucket latency signals.

Security

Repository API secrets are stored encrypted and are only decrypted in Bridge Node memory; they cannot be recovered later from the UI. Bridge Nodes can be registered to the platform via cryptographic signature verification (RSA) tied to an organization key—no traditional auth required.

Deployment options

Flashback runs public Bridge Nodes you can use to get started, and you can also deploy your own nodes inside your cloud tenants to reduce egress and keep traffic local.

Quick start

  • Point your S3/GCS/Azure client to a Bridge Node URL and use your repo-scoped keys.

  • List active nodes and poll GET /stats/nodes/minute to rank endpoints by recent latency and availability.

  • Cache the chosen endpoint briefly (60–120 s) and invalidate on timeouts/5xx to trigger fast failover.

Public Bridge Node

A Public Node is a Bridge Node that Flashback runs for you. It exposes standard S3/GCS/Azure Blob endpoints under the *.flashback.tech pattern, so your apps can talk to one URL and reach buckets across AWS, GCP, or Azure without changing SDKs or creds. Flashback operates and monitors these nodes (latency, health, reachability), making them ideal for instant onboarding, demos, CI, and cross-cloud routing. You get zero deploy/ops, smart endpoint selection (pick the fastest/nearest), and a clean upgrade path to Private Nodes later if you need stricter network boundaries or to minimize egress.

Flashback has deployed bridge nodes in the following providers and regions for testing purposes. Public nodes are recommended for testing purposes but using private nodes is mainly recommended for privacy and cost management.

Properties

Use the following URL pattern to reach any Bridge Node:

https://<api>-<region>-<provider>.flashback.tech

  • <api>

    • s3 (for S3-compatible access)

    • gcs (for GCS-compatible access)

    • blob (for Azure Blob access)

  • <region>

    • us-east-1

    • eu-central-1

  • <provider>

    • aws

    • gcp

    • azure

Examples (region = us-east-1, provider = aws):

  • S3 API: https://s3-us-east-1-aws.flashback.tech

  • GCS API: https://gcs-us-east-1-aws.flashback.tech

  • Blob API: https://blob-us-east-1-aws.flashback.tech

Endpoint Data

Because latency is typically lowest when your Bridge Node is both geographically close and on the same cloud provider as your bucket, it’s best to connect to the node that gives you the fastest response. To help you choose, each Bridge Node publishes real-time stats in the Storage Bucket details view:

  • Status

    • ⏺ Online (e.g. “Online 12 ms”) – the node is up and responding in the shown time.

    • ⏺ Disconnected – the node attempted authentication but received an unauthorized error.

    • ⏺ Offline – the node cannot reach the bucket endpoint at all/

  • Latency Measured in milliseconds by issuing a HeadBucket request against your bucket and timing the round-trip.

Private Bridge Node

A Private Bridge Node is the same stateless API proxy as a Public Node—speaking S3, GCS, or Azure Blob—but runs inside your own cloud account/VPC/VNet. It gives you the same one-client, multi-cloud abstraction while keeping data paths private, reducing egress, and letting you enforce your own network and compliance controls.

How it’s reached

  • Internal-only (recommended): Place the node on a private subnet and expose it via an internal load balancer, service mesh, or PrivateLink/Private Service Connect equivalent.

  • Custom domain (optional): Point a DNS name you control (e.g., s3.internal.example.com) to the node.

  • Protocol surface: The node exposes the same APIs as Public Nodes:

    • s3 (S3-compatible)

    • gcs (GCS-compatible)

    • blob (Azure Blob–compatible)

Tip: keep your app’s SDK config identical to public usage—only the endpoint/base URL changes to your private address.

Keys & auth

  • Use your Repository-scoped access key and secret (the same pair you’d use against a Public Node).

  • Keys are validated by the node against your Flashback repo; bucket routing still follows your Repository policy.

  • Secrets remain encrypted at rest and are only decrypted in node memory during request handling.

Routing & performance

  • The Private Node applies the same provider/bucket routing rules as your Repository.

  • For lowest latency and lowest egress, co-locate each Private Node with the buckets it primarily serves (same cloud + region).

  • You can run multiple Private Nodes (e.g., one per region) and choose the nearest in your app’s config or via your own health-based picker.

Health & status (what you’ll see in Flashback)

Private Nodes report into the platform just like Public Nodes, so the Storage Bucket view will show per-node status and latency:

  • Online (e.g., “Online 12 ms”): node is up; round-trip based on a HeadBucket probe.

  • Disconnected: node reached Flashback but failed auth (check repo keys/registration).

  • Offline: node can’t reach the target bucket endpoint (check routing, VPC egress, DNS, firewall, or cloud endpoint health). Latency is measured in milliseconds using periodic HeadBucket checks.

Registration & security

  • Register the node to your organization so it can fetch repo metadata and emit health metrics.

  • Run it under the minimum network policy required to reach:

    1. your target storage endpoints (AWS/GCP/Azure as configured), and

    2. Flashback’s control plane for secure heartbeats/metrics.

  • Lock down inbound access to your app networks only (security groups/NSGs, firewall, mesh policy).

Deployment patterns

  • AWS: ECS/Fargate or EKS behind an NLB/ALB; optionally expose through VPC Endpoint/PrivateLink.

  • GCP: GKE or managed instance group behind Internal HTTP(S) LB or PSC.

  • Azure: AKS or VMSS behind Internal Load Balancer or Private Link Service.

  • Bare metal/DC: Any container orchestrator; front with your internal L4/L7 proxy.

Quick start

  1. Deploy the Bridge Node container in your VPC/VNet and put it behind an internal LB. (Tutorial soon)

  2. Register it to your Flashback organization (so health + stats appear).

  3. Point your SDK to the node’s private URL:

    • S3 clients: set endpoint_url to your private host; keep accessKeyId/secretAccessKey as repo keys.

    • GCS/Azure clients: set the base URL similarly; use the repo-scoped credentials.

  4. Verify health in Flashback: status should be Online with a low HeadBucket latency.

  5. Lock down inbound ACLs and outbound routes (only the storage endpoints and Flashback control plane).

Troubleshooting

  • Disconnected: rotate repo keys or re-register the node.

  • Offline: check DNS, NAT/egress rules, service endpoints, or cloud-to-cloud firewall.

  • High latency: move the node closer to the bucket region, or provision one Private Node per major region and choose the nearest.

PreviousRepositoriesNextConfigure External or Delegated Credentials

Last updated

Was this helpful?