Getting access

Vectadyne is in private beta. There is no self-serve signup yet, and no public GA date — when one exists it will be stated here rather than implied.

What you need

Two values, and nothing else:

VECTADYNE_MCP_URL	your tenant’s MCP endpoint
VECTADYNE_TOKEN	a bearer token for a principal in that tenant

Every page on this site reads both from the environment. No page prints a literal endpoint or credential, which is deliberate: a docs sample that hardcodes a URL is a sample that sends somebody to the wrong control plane.

export VECTADYNE_MCP_URL="…"   # from your onboarding
export VECTADYNE_TOKEN="…"     # keep this out of your shell history

Before a token arrives

One call works without authentication, and it is the first step of the quickstart for that reason:

curl -s "$VECTADYNE_MCP_URL" \
  -H 'content-type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"server/discover"}'

server/discover proves the endpoint is reachable and tells you which protocol version and verbs it serves. If that works and everything else returns unauthenticated, your networking is fine and you are waiting on a credential — which is a much better place to be than not knowing which of the two is wrong.

Tokens for people, credentials for machines

A bearer token identifies a principal. For a human at a terminal that is you. For anything that runs unattended — CI, a scheduled agent, a fleet member — you want a machine principal with its own credential, its own scope, and its own audit trail, rather than a person’s token in a secret store.

See Enrol a machine principal. Do this before you put anything in CI; retrofitting identity onto an audit log that already blames a human is not fun.

Joining the beta

Request access from vectadyne.ai. Design partners get repository access as well, which unlocks running locally.