Skip to main content
Hyperterse separates compilation from execution. You build once in a trusted environment, then deploy the resulting artifact anywhere. The artifact contains everything the server needs to run — no source files, no build tools, no package manager. This separation gives you deterministic deployments (the validated manifest is the one that runs), faster startup (no filesystem scanning at boot), and a smaller attack surface (source files stay out of the artifact).

​
Build

Compile your project into a self-contained output directory: 
hyperterse build -o dist
This loads .hyperterse from the current directory, discovers all adapters and tools, bundles scripts, and writes the deployment artifact. To build from a different project directory, pass a positional argument: 
hyperterse build path/to/project -o dist
The output directory contains:
ArtifactDescription
hyperterseRuntime binary
model.binSerialized manifest (adapters, tools, config)
build/vendor.jsShared dependency bundle (if tools import npm packages)
build/tools/<name>/*.jsPer-tool script bundles
Always run hyperterse validate before building. The build command also validates, but catching errors early keeps your CI pipeline fast.

​
Serve

Boot from a pre-built artifact: 
hyperterse serve dist/
The serve command deserializes model.bin, reconstructs the project, initializes connectors in parallel, registers MCP tools, and starts the HTTP server. There is no re-parsing of source files. You can also point directly to the manifest: 
hyperterse serve dist/model.bin

​
Deployment workflow

Deployment workflow: validate, build, test locally, ship artifact, serve
The principle is: build once, deploy the artifact. Do not rebuild in the target environment.
1

Validate

Run hyperterse validate to catch configuration errors before building.
2

Build

Run hyperterse build -o dist to produce the deployment artifact.
3

Test locally

Run hyperterse serve dist/ to verify the artifact works before shipping.
4

Ship

Package the dist/ directory into your deployment target — a container image, a tarball, or a direct copy.

​
Environment configuration

The dist/ directory contains no secrets. All credentials are supplied at runtime through environment variables: 
DATABASE_URL="postgresql://..." API_KEY="sk-..." hyperterse serve dist/
Set variables through your platform’s secrets management: Docker Compose env_file, Kubernetes Secrets, cloud provider environment config, or platform dashboards. See Environment variables reference for the full list of supported variables.

​
Horizontal scaling

Hyperterse is a single-process stateless server. Scale by running multiple instances behind a load balancer:
  • Each instance has its own in-memory cache — no inter-instance coordination needed.
  • All instances require the same database endpoints and environment variables.
  • Use sticky sessions if you need MCP session continuity across requests.

​
CI/CD integration

Automate the validate-build-deploy cycle in your pipeline: 
name: Build and Deploy
on:
  push:
    branches: [main]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: hyperterse validate
      - run: hyperterse build -o dist
      - uses: actions/upload-artifact@v4
        with:
          name: hyperterse-dist
          path: dist/

​
Next steps

Choose a deployment method based on your infrastructure:

Docker

Container images for portable deployment

Kubernetes

Orchestrated deployment at scale

Bare metal

Direct binary deployment on servers
Or deploy to a specific cloud provider:

AWS

ECS Fargate

Google Cloud

Cloud Run

Azure

Container Apps

Railway

Managed containers

DigitalOcean

App Platform

Cloudflare

Edge security layer

Vercel

Frontend proxy