vlaport

In development · early access for design partners

Managed inference endpoints for robot policies, hosted in the EU

vlaport is building managed inference endpoints for robot policies (π0/π0.5, SmolVLA, openpi/LeRobot), hosted in the EU. Keep your openpi or LeRobot client, and let your own AI agents set up, deploy and monitor endpoints through our MCP server.

Become a design partnerHow it works
Robot arm connected to an EU-hosted vlaport endpointA robot arm on the left sends observations to a vlaport endpoint in an EU GPU region on the right, which returns chunks of actions.observationsaction chunksEU GPU regiongateway · JWT checkfleet scheduleryour policydedicated GPU

The problem

Robot policies outgrew the robot

Robots are increasingly controlled by vision-language-action (VLA) models. Serving them well is a hard systems problem that most robotics teams should not have to solve themselves.

  • On-robot compute caps the model

    The computer on the robot limits how large a vision-language-action policy can be and how fast it runs.

  • Remote GPUs make actions stale

    Moving inference to a GPU over the network adds delay, so actions can arrive after the scene has changed.

  • Self-hosting is a second job

    Teams run research servers such as openpi and LeRobot themselves, and have to operate GPUs, networking and security on top of robot learning.

How it works

Two paths: your agent configures, your robot infers

The MCP server is the control plane. The openpi/LeRobot-compatible endpoint is the inference path. Read the details.

  1. Step 1: Connect your agent

    Add the vlaport MCP server (in development) to the AI agent you already use. It is a thin client of the vlaport API and acts only with your credentials, inside your organisation.

  2. Step 2: Register a policy and a project

    Your agent registers your policy weights and creates a project. Each project maps to its own isolated namespace.

  3. Step 3: Deploy an endpoint

    Your agent deploys the policy to a GPU in the EU region. GPU deployments are approved and given a quota before they run.

  4. Step 4: Point your robot at it

    Your robot's openpi or LeRobot client connects to <company>-<project>-<id>.vlaport.com with an API token. Status and latency come back through the same agent.

vlaport architecture: control plane and inference pathTop lane, control plane: your AI agent calls the vlaport MCP server, which calls the vlaport API, which deploys your policy into your isolated project namespace. Bottom lane, inference path: your robot's openpi or LeRobot client connects to the edge gateway, which checks the JWT and forwards the request to your policy on a dedicated GPU.CONTROL PLANEINFERENCE PATHYour AI agentthe one you already usevlaport MCPin developmentvlaport APIsource of truthdeploysnamespace <company>-<project>default-deny networkingYour policyπ0/π0.5, SmolVLA, … on a dedicated GPUYour robotopenpi / LeRobot clientEdge gatewayJWT validated before the podobservationsaction chunks
The MCP server is the control plane; the openpi/LeRobot-compatible endpoint is the inference path. Robots never talk to the MCP server, and agents never sit in the action loop.

Capabilities

Built for robots, not generic inference

What the MVP is being built to do, and what is on the roadmap.
  • Planned for the MVP

    Drop-in for openpi and LeRobot

    The endpoint speaks the openpi WebSocket and LeRobot gRPC async-inference protocols, so existing clients only change the endpoint URL and API key. Async action chunking keeps the robot executing while the next chunk is computed, to keep latency low.

  • Planned for the MVP

    Deadline-aware fleet scheduling

    Requests are scheduled by each robot's action deadline rather than first-in, first-out, so a fleet shares GPU time without the robot that needs actions soonest waiting behind the others.

  • Planned for the MVP

    Multi-tenant isolation

    Every company project gets its own namespace with default-deny networking, its own credentials and, in the MVP, a dedicated GPU. Requests are authenticated at the edge before they reach a model.

  • Planned for the MVP

    Run by your own AI agents

    Your agents set up, deploy and monitor endpoints through the vlaport MCP server: register, configure, deploy and check status. The same server works for operators and CI pipelines, and it never sits on the real-time path.

  • Planned for the MVP

    Per-robot latency telemetry

    See p50 and p99 latency, action staleness and buffer under-runs for every robot, so you know when the network rather than the model is the problem.

  • Roadmap

    Edge–cloud split

    A small edge policy next to the robot corrects cloud action chunks and requests new ones only when it is uncertain, to bridge short network outages.

Drop-in endpoint

Keep your openpi or LeRobot client

Point the client you already use, such as openpi's WebsocketClientPolicy or a LeRobot policy client, at your vlaport endpoint. The protocol stays the same, so there is no new SDK to adopt.

Async action chunking lets the robot keep executing the current chunk while the next one is computed, so network delay is largely overlapped with execution rather than added to every step.

Policy families we are building for

  • π0 / π0.5 · openpi
  • SmolVLA · LeRobot
  • GR00T · bring your own licensed weights
  • OpenVLA · bring your own weights

Design targets for the MVP. You bring your own weights, under their licences.

Python · openpi clientpython
from openpi_client import websocket_client_policy

# Before: a self-hosted openpi policy server
# policy = websocket_client_policy.WebsocketClientPolicy(host="localhost", port=8000)

# After: your vlaport endpoint (same client, same calls)
policy = websocket_client_policy.WebsocketClientPolicy(
    host="<company>-<project>-<id>.vlaport.com",
    # plus your vlaport API key: only the endpoint URL and API key change
)

action_chunk = policy.infer(observation)["actions"]

Illustrative. Final connection details are shared with early-access partners.

MCP interface

Your agents run your endpoints

Customers work with vlaport through their own AI agents. The vlaport MCP server (in development) registers, configures, deploys and reports the status of policies and endpoints. It is usable by operators, CI pipelines and AI agents, and never sits on the real-time path. See the MCP tools.

  • register

    Register a policy and its weights with your organisation.

    Planned for the MVP

  • project

    Create or inspect a project, which maps to its own isolated namespace.

    Planned for the MVP

  • deploy

    Deploy a registered policy version as an inference endpoint.

    Planned for the MVP

  • status

    Report endpoint health and the current p50 and p99 latency.

    Planned for the MVP

  • invite member

    Company admins invite colleagues into the organisation.

    Planned for the MVP

  • logs and latency history

    Inspect endpoint logs and historical latency.

    Roadmap

The web app at app.vlaport.com is mostly read-only views plus API token management.

Multi-tenancy and security

Isolation by design

Each company project is fenced off at the namespace, network, identity and GPU level. Read the security model.

  • Namespace per company project

    Each project runs in its own Kubernetes namespace, named <company>-<project>. Tenants cannot create workloads there directly; only the vlaport control plane does.

  • Default-deny networking

    Network traffic between namespaces is denied by default with Cilium policies. Only the routes vlaport creates for your endpoint are open.

  • Authentication at the edge

    Endpoint requests carry a JWT issued through Authentik. The gateway validates it before a request reaches your model.

  • Dedicated GPU in the MVP

    In the MVP each tenant's predictor runs on a dedicated GPU. Sharing GPUs across tenants is not part of the MVP.

Latency telemetry

See every robot's latency

Per-robot telemetry shows where time goes, so you can tell a network problem from a model problem.
p50 and p99 latency
Per robot and per endpoint, also returned by the MCP status tool.
Action staleness
How old an action is by the time the robot executes it.
Buffer under-runs
When a robot runs out of queued actions before the next chunk arrives.

How we build

Engineered by AI agents, accountable to a human

vlaport builds its software with AI coding agents working under human control. The founder and CEO is the accountable lead and takes the architecture, product, IP and safety decisions. About vlaport.

  • Human approval gates: no merge to main and no architecture decision without approval by the accountable human; decisions recorded as ADRs
  • Evaluator-agent review: every pull request is reviewed by a separate Evaluator agent against tests, specs and security rules
  • CI test and coverage gates (planned): tests and a minimum coverage threshold will have to pass before merge
  • Release gates: releases will ship only after benchmark, safety and security checks and a human sign-off
  • Safety-relevant behaviour and IP filings are decided by the founder only

Roadmap

Where we are going

Plans, not promises. TRL 4 now; TRL 5 is the planned MS0 milestone.

  1. 1. Building now

    MVP platform

    • MVP release targeted for January 2027
    • Multi-tenant Kubernetes platform with isolated namespaces and default-deny networking
    • openpi- and LeRobot-compatible endpoints with async action chunking
    • Core MCP tools: register, project, deploy, status and member invite
    • Per-robot latency telemetry and API token management

  2. 2. Planned next

    Real-robot validation (MS0, planned)

    • Planned MS0 milestone: a real robot arm running π0.5/SmolVLA from an EU GPU region over wired WAN and 5G, against local inference
    • Deadline-aware fleet scheduler measured against FIFO scheduling
    • Early access for design partners

  3. 3. On the roadmap

    Beyond the MVP

    • Edge–cloud split serving with a small edge policy
    • Shadow and A/B rollout of policy versions
    • MCP log and latency-history tools
    • A second EU region and high-availability hardening

Become an early-access design partner

vlaport is in development. We are looking for robot-learning teams who serve openpi or LeRobot policies today and want to shape a managed, EU-hosted endpoint with us. Tell us about your robots and policies.

Email contact.eu@vlaport.com

Sign-up is by email only. This site has no forms, sets no cookies and collects no personal data.