Skip to content
Secure Ingress
Documentation
Getting Started

Getting Started

Getting Started: The steps below walk you through the Altuur Secure Ingress onboarding workflow. Contact us if you need help.

Go from zero to a globally reachable, authenticated service in four steps: create a project and a service account in the Console, deploy Warpgate next to your workload, configure routes, and go live.

Prerequisites

  • A workload (web app, API, or any service) running on any platform. 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, framework, or deployment target required.
  • Docker or Kubernetes for running Warpgate
  • A Secure Ingress account (create one in the Console )

For this guide, we’ll assume your web service listens on port 8080, either inside a container or directly on the host.

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

Warpgate authenticates with a service account API key, so create the credential before you deploy anything. Open the Console:

  1. Create a project: give it a name and description
  2. Create an environment: production, staging, or development; each environment gets its own endpoint hostname
  3. Add a service account: open the project’s Service Accounts, create one, and copy the generated API key. This is the Warpgate token (YOUR_API_KEY below); it is shown once.

Step 2: Deploy Warpgate next to your workload

Deploy the Warpgate alongside your workload. Warpgate connects outward to the Altuur Edge, so no inbound ports need to be opened on your infrastructure. Warpgate reaches your application over a private network path; the application itself is never published to the internet.

Using Docker Compose (recommended)

Run the application and Warpgate as two services on the same Compose project. Compose gives them a private network, so Warpgate reaches the application by service name, and the application has no ports: entry: it is reachable only from inside that network.

services:
  app:
    image: your-app:latest
    # No ports: the app is reachable only on the private Compose network

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

Using Docker with an application on the host

If the application runs directly on the host rather than in a container, map the host into the Warpgate container and point the upstream at it. Inside a container, localhost refers to the container itself, not the host.

docker run --add-host=host.docker.internal:host-gateway mezusphere/warpgate \
  --api-key YOUR_API_KEY \
  --upstream-url http://host.docker.internal:8080

This variant assumes the application listens on the host and accepts connections from the Docker bridge network (for example by binding to 0.0.0.0:8080), and that port 8080 is not exposed publicly: your host firewall or cloud security group must keep it closed to the internet. Only Warpgate should be able to reach it.

Optional: verify connectivity with echo mode

Before wiring your upstream, you can confirm the path end to end. With --echo, Warpgate answers every request through your endpoint with a JSON reflection of the request it received:

docker run mezusphere/warpgate --api-key YOUR_API_KEY --echo

Open your environment’s endpoint in a browser. When the echo response appears, replace --echo with --upstream-url and traffic flows to your service instead.

Close the direct path

Adding Warpgate does not remove an existing public IP address, listener, or firewall rule. If your application was reachable from the internet before, remove the published port, the DNS record, or the security-group rule that exposed it, or restrict it to trusted addresses, so that the only route to the workload is through the Altuur Edge. The security properties described in the Security section depend on this.

Step 3: Configure routes in the Console

Back in the Console, open the environment you created:

  1. Define routes: set up URL path routing rules to your backend
  2. Enable authentication (optional): require end-user login on specific routes; routes you leave public (for example a health check) pass through without end-user authentication

Step 4: Go live

Once configured, end users connect through the Altuur Edge. Their traffic is automatically:

  • Encrypted with TLS 1.3
  • Protected by edge rate limiting and abuse controls
  • Authenticated on the routes where you enabled it, before reaching your Warpgate
  • Routed to the correct backend based on your path rules

Your service is globally reachable and secured without any changes to your application code.

What’s next