Rivet Cloud
Managed Rivet: we run the control plane, and can run your backend too.
Rivet Cloud runs the control plane for you. You keep writing the same code and deploy it one of two ways:
- Bring your own compute. Run workers on your own infrastructure and point them at Rivet Cloud. Every platform in the Self-Host worker guides works this way.
- Rivet Compute. Hand Rivet a container and it runs your backend as well. See Rivet Compute.
Nothing here is required to use Rivet. If you would rather run the control plane yourself, see Deploy.
Getting started
- Create a project at dashboard.rivet.dev.
- Open Connect and pick how you want to deploy.
- Copy the endpoint values, or the cloud token if you are deploying with Rivet Compute.
Tokens
Rivet Cloud issues three kinds of token, and mixing them up is the most common source of 401s.
| Token | Prefix | Scope | Used for |
|---|---|---|---|
| Secret | sk_ | Engine API at api.rivet.dev | RIVET_ENDPOINT, server-side only |
| Publishable | pk_ | Engine API at api.rivet.dev | RIVET_PUBLIC_ENDPOINT, safe for browsers |
| Connection | ck_ | Engine API at api.rivet.dev | A strict subset of publishable: resolve actors and open connections, but not manage them |
| Cloud API | cloud_api_ | Cloud API at cloud-api.rivet.dev | rivet deploy, CI, managed-pool APIs |
A pk_ token will fail against the Cloud API, and a cloud_api_ token will fail against the Engine API. They are not interchangeable.
Create them from the dashboard or the CLI:
rivet token create --namespace production --kind connection
A publishable or connection token is not a user identity. Anyone can copy it out of your bundle and use it, so it is a namespace-wide permission set rather than a per-user boundary. Use a JWT when the boundary has to follow the user.
In this section
- Bring Your Own Cloud: run the control plane in your cloud account with Rivet-assisted deployments
- Rivet Compute: deploy your backend as a container
- Preview Deployments: an isolated namespace per pull request