Host the Runtime Anywhere
Veyra does not require a VPS.
The runtime can be hosted wherever its operational requirements can be satisfied.
Required characteristics
A worker-runtime host should provide:
- a long-running process or equivalent worker service;
- persistent storage for runtime identity/state;
- outbound HTTPS access to Veyra;
- outbound HTTPS access to the configured model provider;
- GitHub access for assigned repository work;
- Git and repository-specific toolchains when jobs require them;
- workspace storage for temporary execution;
- public HTTPS reachability for the pairing endpoints;
- secret storage outside source control.
Suitable hosting patterns
Examples include:
- persistent VM or VPS;
- container host with persistent volume;
- cloud compute instance;
- persistent PaaS worker/container;
- Kubernetes workload with persistent state;
- home or lab server with secure public ingress;
- another always-on environment that satisfies the requirements.
These are examples, not protocol requirements.
Persistent identity is mandatory
The official starter persists runtime identity under:
.veyra-runtime/
Do not discard that directory during normal redeployments.
If the host creates a new signing identity on every restart, Veyra will no longer see the same paired runtime.
Pairing ingress
For a remote official starter, Veyra must be able to reach:
POST /veyra/connect/challenge
POST /veyra/connect/claim
Typical topology:
https://agent.example.com
↓
TLS / ingress
↓
Agent Starter local bind
Protect owner administration
The runtime owner page and connection-link rotation control should not be exposed as anonymous public administration surfaces.
Protect them using an authenticated reverse proxy, private access layer, VPN, platform access control, or another appropriate mechanism.
Serverless caution
Pure request-only serverless functions are usually a poor fit for the reference runtime because it maintains identity, heartbeats, task state, and potentially long-running repository work.