What are the beta limitations?

Relay-first is the supported default. Mobile is foreground-only in public beta. Public beta is not positioned as a full-device always-on VPN and there is no default public discovery fabric.

Animus Link — Relay-First Secure Overlay for Private Service Access

Q: What can operators inspect?

Operators can use health, self_check, diagnostics, metrics, expose, connect, and relay policy endpoints, plus runbooks for launch, smoke tests, and verification.

I · i§ 01

What Animus Link is

Private service accessRelay-first by defaultBuilt for real operators

Animus Link is a secure overlay for connecting selected private services across messy, hostile, or simply inconvenient networks. It is designed for the common problem teams actually have: a service exists somewhere behind NAT, firewalls, or local-only boundaries, and specific people or systems need safe access without broad public exposure.

It is built on Animus Fabric, which provides the underlying secure-session substrate, wire handling, relay control/data behavior, replay protection, and protocol discipline. Animus Link is the product and operator surface on top: daemon, mobile and desktop hosts, local API, managed relay policy, diagnostics, and release/verification workflows.

Positioning in one sentence

Core positioning
Animus Link is a relay-first secure overlay for connecting selected private services across NATs and untrusted networks with invite-first onboarding, end-to-end encrypted paths, signed relay admission, and operator-grade controls.

What it is not

Is

A relay-first secure overlay for selected private services.
An Expose / Connect service model with explicit peer access control.
A product surface with local API, diagnostics, metrics, and signed relay admission.

Is not

Not a Tor-class anonymity system.
Not a default full-device, full-tunnel VPN product in public beta.
Not a public DHT-style open discovery network.

I · ii§ 02

How it works

The model is intentionally simple, because operational security gets worse when the product story is vague.

Step	What happens	Why it matters
`01`	Users create or join private namespace invites.	Discovery is invite-first instead of globally enumerable.
`02`	Clients establish relay-first paths across NATs and untrusted networks.	Connectivity works in the environments that usually break direct access.
`03`	Relays accept signed allocation tokens and enforce TTL/quota policy.	Admission and resource control are operationally enforceable, not informal.
`04`	Services are exposed explicitly with `allowed_peers`.	Access is deny-by-default, not retrofitted after exposure.
`05`	End-to-end encrypted frames pass through the relay without relay decryption.	The relay helps connectivity without becoming the trust anchor.

Relay-first path

Path / relay-first / service access / end-to-end protected

A

client / operator

Relay · admits · routes · stays opaque

B

private service

discoveryinvite-first admissionsigned token exposureexplicit peers only payloadnot decrypted by relay

flowchart LR
  I[Invite-scoped namespace] --> C[Client / host app]
  C -->|signed token + ciphertext| R[Managed relay path]
  R -->|opaque forwarding| S[Exposed private service]
  S -->|Connect| C

I · iii§ 03

Concrete use cases

Dev access

Expose a private dev service and connect securely from a laptop or mobile host app without opening broad inbound access.

Home lab

Publish selected internal services without turning your router and firewall into a permanent public attack surface.

Small team internal tools

Give signed, relay-first access to staging or admin services with explicit peer allow-lists and operational visibility.

Operator workflows

Validate health, self-check, diagnostics, and metrics before exposing services or rolling beta access wider.

What matters commercially is that these are not hypothetical categories. They map directly to the product surface already present in the repository: local daemon, relay server, service exposure, operator runbooks, verification flows, and platform hosts.

II · i§ 04

What the relay sees — and what it never should

Animus Link is explicit about the relay boundary. That clarity is more valuable than a vague promise of “secure by design.”

Relay can observe	Relay must not observe
Source IP and connection pattern Timing and byte counts Routing / binding metadata Allocation and quota state	Plaintext payload Session keys Handshake secrets Service content

Security model highlights

Identity

Self-certifying NodeID with suite-independent identity continuity.

Replay protection

Anti-replay is specified with a sliding window and rekey thresholds.

Discovery

Invite-first by default, with no default public directory.

Logging discipline

Secrets, tokens, keys, and plaintext are treated as must-never-log material.

II · ii§ 05

Truths, limits & honest claims

Animus earns trust by separating what is implemented now, what is scaffolded, and what is still planned or target-only. That makes the landing useful to engineers and reassuring to serious buyers.

Truth	Why it matters
Relay-first is the supported public-beta path.	The product is optimized for real connectivity conditions, not ideal-network demos.
Signed relay tokens are the default beta posture.	Admission, quota, and operator policy are part of the product story from day one.
Mobile is foreground-only in public beta.	The product does not overclaim always-on behavior where platform policy still dominates.
Full-device gateway / tunnel behavior is not the public-beta default.	Optional or internal-beta tunnel modes stay clearly bounded.
Public discovery is not the default model.	The product favors scoped participation and deliberate access over open enumeration.

!

No hype layer. This page deliberately avoids invented latency numbers, fake anonymity claims, and vague “enterprise-grade” language. The repo is strongest when it speaks precisely, so the landing does too.

III · i§ 06

Operator controls

Animus Link is engineered for operators, not just end users. The local API and runbooks make status, exposure, diagnostics, and verification first-class.

Core operator endpoints

Endpoint	Purpose
`GET /v1/health`	Basic daemon liveness and API availability.
`GET /v1/self_check`	Safe validation of core checks without exposing secrets.
`GET /v1/diagnostics`	Redacted config, counters, and aggregated error state.
`GET /v1/metrics`	Prometheus-compatible metrics for operational monitoring.
`POST /v1/expose`	Publish a selected service with explicit `allowed_peers`.
`POST /v1/connect`	Connect to an exposed service path.
`POST /v1/services/expose`	Service-surface exposure for the service bridge model.
`POST /v1/services/connect`	Connect through the service bridge model.

Operational posture

Relay admission

Signed relay tokens are enabled by default for beta launch and validation flows.

Quota policy

Quota limits, issuer/subject controls, and allocation bounds are part of the relay runbook.

Verification

Release verification, smoke tests, integrity files, and redaction discipline are documented explicitly.

Diagnostics discipline

Self-check and diagnostics are designed to stay useful without leaking invites, tokens, or keys.

$ curl -fsS http://127.0.0.1:9999/v1/self_check
$ curl -fsS http://127.0.0.1:9999/v1/diagnostics
$ curl -fsS http://127.0.0.1:9999/v1/metrics
$ curl -s -X POST http://127.0.0.1:9999/v1/expose \
    -H "content-type: application/json" \
    -d '{"service_name":"echo","local_addr":"127.0.0.1:19180","allowed_peers":["peer-b"]}'
      

III · ii§ 07

Platform surfaces

Desktop

Desktop host surfaces sit above the same Fabric core and daemon/API model, with operator-friendly workflows and verification scripts.

Android

Android host app uses the Fabric FFI surface, foreground-service beta posture, and signed relay-token path by default.

iOS

iOS host app and packet tunnel extension are documented with foreground-only public-beta policy and redaction checks.

CLI + daemon

The daemon and CLI remain the clearest operator surface for health checks, service exposure, and scripted verification.

Shared product logic

flowchart LR
  F[Animus Fabric core] --> D[link-daemon / local API]
  F --> A[Android host app]
  F --> I[iOS host app]
  F --> X[Desktop shell]
  D --> O[Operator workflows]

IV · i§ 08

Public beta limits

These limits do not weaken the product story. They strengthen it by making the current surface falsifiable and understandable.

VPN scope

Public beta is not a general full-device full-tunnel VPN default. The core story is secure access to selected services.

Mobile runtime

Mobile is foreground-only in beta. Always-on background connectivity is not promised.

Discovery

There is no default public discovery fabric or public participant directory.

Future architecture

Transport expansion, gateway evolution, and broader topology work remain clearly separated from current beta guarantees.

Why this is commercially strong

Serious infrastructure buyers do not want a landing page that pretends roadmap work is already shipped. They want a team that understands system boundaries, makes deliberate claims, and can explain exactly where operational responsibility begins and ends. Animus Link already reads that way in the repository. This landing simply makes that legible.

IV · ii§ 09

Search-friendly FAQ

Is Animus Link a VPN?

Not in the default public-beta sense. Animus Link is a relay-first secure overlay for selected service access using Expose and Connect, not a general full-device full-tunnel VPN by default.

Does the relay decrypt traffic?

No. The relay forwards opaque encrypted frames and does not terminate end-to-end payload encryption.

How is access controlled?

Service exposure is deny-by-default. Exposed services require explicit allowed_peers, and relay admission is based on signed tokens in the supported beta posture.

What can operators inspect?

Operators can inspect health, self-check, diagnostics, metrics, service exposure state, and relay policy behavior without treating the relay as a trusted content endpoint.

Why is mobile foreground-only?

The beta intentionally avoids overpromising background behavior where platform policy still dominates. Foreground-only keeps the current product honest and testable.

Who is this for?

Teams and operators who need secure access to selected private services — developer environments, internal tools, home lab services, or relay-governed service paths — without making the public internet their default trust boundary.

IV · iii§ 10

Get started

Relay-first Invite-first Operator-grade

Start with the repo, validate the runbook,
then expose only what you intend to expose.

Animus Link is strongest when evaluated the same way it is engineered: by reading the spec, verifying the beta posture, and checking the operator surface directly.

Best entry points: positioning, public beta FAQ, public beta runbook, and the production reference README.

Open repository ↗ Read positioning Read beta runbook

Closing line
Private services do not need more hype. They need a safer path, a smaller trust boundary, and controls operators can actually verify.

Private service access without exposing your infrastructure.

Positioning in one sentence

What it is not

Relay-first path

Security model highlights

Core operator endpoints

Operational posture

Shared product logic

Why this is commercially strong

Is Animus Link a VPN?

Does the relay decrypt traffic?

How is access controlled?

What can operators inspect?

Why is mobile foreground-only?

Who is this for?

Private service access
without exposing your
infrastructure.