How Vecta Works

Vecta coordinates backups from a hosted dashboard while your server runs restic and writes directly to your storage.

Three places, three responsibilities

Your Linux server                 vectaapp.com                 Your storage
agent + restic  <--- HTTPS --->  job config, status, history  encrypted repository
       \______________________________________________________________/
                    backup data does not pass through the dashboard

The agent makes outbound HTTPS requests. It pulls the work that is due, runs restic locally, writes to the destination, and reports progress.

What lives where

Location	Stored or performed there
Dashboard	Account details; agent names, IDs, versions, and check-ins; job configuration including source paths and destination URLs; run status, counters, snapshot IDs, and short failure-message tails
Agent machine	Agent API key; destination credentials; repository password; restic process and local log
Your storage	Encrypted, deduplicated restic snapshots and their repository data

The destination URL is metadata, so the dashboard knows where a job writes. Storage credentials and the repository password stay on the agent machine.

The pull model

The agent is not a long-running inbound service. A scheduled invocation asks the control plane what is due and whether a run should stop. The details are in The pull-based agent model.

Security boundary

The control plane coordinates metadata but is not in the backup data path. See Zero-access security for the precise boundary and its limits.

What's next

Start with The pull-based agent model, then read Job lifecycle & statuses.