Skip to content

Documentation

Documentation: This documentation describes the Altuur Secure Ingress platform architecture and features. Secure Ingress is live in pilot today and launches publicly in October 2026. Request pilot access to get started, or contact us if you need help.

Welcome to the Secure Ingress documentation. This is your starting point for understanding how Secure Ingress works, deploying your first service, and managing your infrastructure through the Console.

Secure Ingress unifies traffic ingress, authentication, authorization, and routing into a single software layer. Instead of configuring inbound traffic through layers of proxies and gateways, your workloads connect outward to Secure Ingress through a lightweight sidecar called a Warpgate. End-user traffic enters through Altuur’s global edge, which handles TLS, authentication, and routing before forwarding requests to your Warpgate.

The result: deploying a secure, globally reachable internet service becomes a single repeatable pattern, regardless of cloud provider, language, or deployment platform.

Getting Started

You can go from zero to a globally reachable, authenticated service in four steps. Secure Ingress is cloud-agnostic: your application can run on any cloud provider, in a container, on a virtual machine, or on your local development machine, with no specific runtime or deployment target required.

Step 1: Create a project and a service account in the Console

Open the Console, create a project and an environment, then add a service account. Its API key is the token Warpgate uses to authenticate, so create it before you deploy.

Step 2: Add the Warpgate sidecar

Deploy the Warpgate alongside your workload. Warpgate connects outward to Secure Ingress, so no inbound ports need to be opened on your infrastructure, and it reaches your application over a private network path: with Docker Compose, by service name on the private Compose network, with no ports: entry for the application.

services:
  app:
    image: your-app:latest

  warpgate:
    image: mezusphere/warpgate
    command: ["--api-key", "YOUR_API_KEY", "--upstream-url", "http://app:8080"]
    depends_on:
      - app

Adding Warpgate does not remove an existing public IP, listener, or firewall rule; close those so the only route to the workload is through the edge. The Getting Started guide covers the host-networking variant and echo mode.

Step 3: Configure routes in the Console

Back in the Console, define URL path routing rules, set authentication requirements per route, and manage user access. The Console gives you full control over how traffic reaches your workload.

Step 4: Go live

Once configured, end users connect through the Altuur Edge. Requests on protected routes are authenticated and authorized before they reach your workload; public routes pass through without end-user authentication. All traffic is routed to your Warpgate automatically. Your service is globally reachable and secured without any changes to your application code.

Core Concepts

Organizations

The top-level entity in Secure Ingress. An organization groups projects, billing, and team access. Everything in Secure Ingress belongs to an organization.

Projects

A logical grouping of environments, routes, Warpgates, and service accounts under an organization. Projects represent a single service or application that you want to expose through Secure Ingress.

Environments

Named deployment targets within a project, such as Development, Staging, and Production. Each environment has its own endpoint URL and can be independently enabled or disabled.

Routes

URL path routing rules within a project. Routes determine how incoming requests are directed to your workload. Secure Ingress supports three matching modes:

  • Prefix: matches any path starting with the specified value
  • Exact: matches the path exactly
  • Regexp: matches using a regular expression

Routes can require authentication and specific permissions. CORS configuration is also supported per route.

Warpgates

Lightweight sidecars deployed alongside your workloads. Warpgates register themselves with the control plane using service account credentials. They report their status (connected, disconnected, or unknown) and IP address. Warpgates cannot be created through the Console; they register themselves automatically when deployed.

Service Accounts

Machine credentials used for Warpgate registration and API access. Each service account has an API key and configurable permissions. Service accounts are scoped to a project.

User Directories

Collections of end-user accounts, scoped to a project or organization. User directories let you manage separate pools of users for different services or for your entire organization.

User Accounts

End users who access services through Secure Ingress. User accounts have a status (active, inactive, or suspended), login tracking, and profile information including name, email, and display name.

Warpgate

Warpgate is the lightweight sidecar agent that connects your workload to Secure Ingress. It implements an inverted ingress model: instead of opening inbound ports and configuring firewalls, Warpgate connects outward to Altuur’s global edge.

Deployment Options

Warpgate can be deployed in several ways:

  • Docker: run the mezusphere/warpgate container image alongside your application, with Docker Compose or docker run
  • Kubernetes: deploy the same image as a sidecar container in your pod

How It Connects

Warpgate initiates an outbound connection to Altuur’s global edge. This means your infrastructure requires no inbound ports, no firewall rules, and no VPN configuration. Warpgate authenticates itself using a service account API key and maintains a persistent connection for receiving traffic.

Cloud-Agnostic

Warpgate works the same way regardless of where your workload runs: AWS, GCP, Azure, on-premises data centers, or your local development machine.

Console

The Console is Altuur’s web-based management UI. It provides a central interface for configuring and monitoring all aspects of your Secure Ingress deployment.

Key Workflows

  • Create projects: set up new services under your organization
  • Configure routes: define URL path routing rules with authentication requirements
  • Enable authentication: require end-user login and set permission-based access controls
  • Manage users: create and manage user directories and user accounts
  • Manage environments: configure deployment targets with endpoint URLs
  • Manage service accounts: create credentials for Warpgate registration
  • View metrics: monitor traffic, authentication outcomes, and system status

Use Cases

Two illustrative scenarios (worked examples, not customer case studies) show how a team could use Secure Ingress to replace a multi-vendor infrastructure stack:

  • Fintech API: a small team secures partner API access with auth, rate limiting, and TLS, with a Compose file edit and a few Console settings
  • Multi-region SaaS: a SaaS team unifies routing, auth, and TLS across AWS and GCP with one Console

Read the full walkthroughs in Use Cases.

Security

Secure Ingress treats security as architecture, not configuration. The outbound-only connectivity model produces structural security guarantees:

  • TLS 1.3 everywhere: all traffic is encrypted, including mutual TLS (mTLS) between Warpgates and edge nodes
  • No public inbound origin required: no open inbound ports, no public IP, and no DNS record pointing at the workload; once you close any pre-existing direct path, there is no discoverable origin
  • Edge-enforced authentication: requests on protected routes are authenticated before they reach your Warpgate; public routes pass through without end-user authentication
  • Defense in depth: security policies enforced at the edge and validated again at the Warpgate

Read the full Security documentation for details on transport security, the authentication model, and data protection.