Egress Firewall Allow-List for Outbound Communication

Defines required firewall egress rules for the product. Lists all outbound hosts, ports, and a strict manifest of what data is and is not sent.

Overview

This document provides the definitive allow-list for outbound network connections required by the product. The product is designed to run entirely within your VPC and does not expose any public endpoints.

All communication with the Specaria platform is initiated by the product as outbound traffic over HTTPS (TLS 1.3+). The Specaria platform will never initiate an inbound connection to your product instance. This document serves as the technical contract for configuring your firewall egress rules and understanding the data that leaves your network.

How it Works

The product's communication model distinguishes between two types of outbound traffic: automated calls from the product backend and user-driven requests from an operator's web browser.

Product Backend: The core product services make automated, server-to-server calls to specific platform endpoints for licensing, updates, and other essential functions.
Operator Browser: An operator interacting with the product may access separate web-based resources like documentation or the main platform portal. The product backend itself does not connect to these hosts.

The hostnames for backend communication (api.specaria.io, updates.specaria.io) are product constants baked into the binary and are not configurable.

The following diagram illustrates the flow of outbound communication from your environment.

flowchart TD
    subgraph "Your VPC"
        direction LR
        PB["Product Backend"]
        OB["Operator Browser"]
    end

    subgraph "Specaria Platform (Public Internet)"
        direction LR
        API["api.specaria.io"]
        UPD["updates.specaria.io"]
        PORTAL["portal.specaria.io"]
        DOCS["docs.specaria.io"]
        STATUS["status.specaria.io"]
        WWW["www.specaria.io"]
    end

    PB -- "HTTPS (TCP 443)" --> API
    PB -- "mTLS (TCP 443)" --> UPD
    OB -- "HTTPS" --> PORTAL
    OB -- "HTTPS" --> DOCS
    OB -- "HTTPS" --> STATUS
    OB -- "HTTPS" --> WWW

Required Egress Endpoints

Your VPC firewall must permit outbound HTTPS traffic (TCP port 443) from the product subnet to the hosts listed below.

Host	Called by	Purpose
`api.specaria.io`	Product backend	Public integration plane: license verification keys (JWKS), the capacity heartbeat, license-request submission, deployment license-acquire, settings, feedback, and the build-time doc-upload pipeline.
`updates.specaria.io`	Product backend	mTLS plane: deployment self-ID register, license poll, and the channel-gated release-manifest poll. The product presents its embedded per-product mTLS client cert here.
`portal.specaria.io`	Operator browser	Operator portal; support-chat surface; in-product documentation/help.
`docs.specaria.io`	Operator browser	Product documentation.
`status.specaria.io`	Operator browser	Platform status page.
`www.specaria.io`	Operator browser	Product marketing pages.

IMPORTANT

Minimum Functional Requirements: For the product to start and operate, the backend requires connectivity to api.specaria.io on first start and updates.specaria.io for licensed updates. Failure to reach these endpoints will impact licensing and updates. The other hosts are for operator convenience and are not called by the product backend.

Configuring an HTTP/HTTPS Proxy

If your environment routes outbound traffic through an HTTP/HTTPS proxy, the product honors standard proxy environment variables. Credentials included in the proxy URL are automatically redacted from logs.

Variable	Description
`HTTPS_PROXY`	The URL of the HTTPS proxy server.
`NO_PROXY`	A comma-separated list of hostnames that should bypass the proxy.
`SSL_CERT_FILE`	The file path to a custom Certificate Authority (CA) bundle for verifying the proxy's certificate.

Data Transmission Policy

The product is designed to send only essential operational metadata to the Specaria platform. This policy ensures that no sensitive information about your traffic, infrastructure, or personnel leaves your network. All outbound payloads are processed through a redaction step to enforce this allow-list.

Data Sent to the Platform

The following categories of data are sent:

Numeric counts: Aggregate numbers, such as capacity counts for discovered or converted services.
Versions: Product version, agent version, and build commit hash.
Hashed host fingerprint: A SHA-256 hash of a hostname. The raw hostname is never sent.
Installation ID: An opaque UUID that identifies a specific product installation.
Customer label: A free-text identifier for the customer, used for informational purposes.
Contact email: An email address used for license request submissions and as the "issued-to" contact on the license.

Data Never Sent

The product is explicitly designed to prevent the transmission of the following data types:

API Traffic: SOAP message bodies, request payloads, or response payloads.
Infrastructure Details: Backend hostnames, internal IP addresses, or internal service names.
Personal Data: End-user names, emails, IDs, or any other Personally Identifiable Information (PII).
Business Data: Service display names or aliases.
Credentials and Configuration: Secrets, service-account keys, environment variable dumps, source code, or configuration files.

Troubleshooting

Symptom: The product fails to start or stops functioning after a grace period.

Cause: This is often caused by a firewall blocking outbound connections from the product backend to the required Specaria platform endpoints.

Resolution:

Verify that the product subnet has an egress rule allowing outbound TCP traffic on port 443 to api.specaria.io and updates.specaria.io.
api.specaria.io is required on the first cold start to fetch license verification keys.
Connectivity to both hosts must be available within the offline grace window for continuous operation.