Sylphx documentation

Sylphx runs your application's supporting services — the deployment, the database, the key-value store, the object storage, the search index, the user accounts, the events, the email, the logs and the AI calls. They are one product, not ten: one account, one key, one bill, and one API at https://api.sylphx.com.

#The first call

Every key can read who it belongs to. There is no setup for it, and no scope to grant.

sylphx access whoami

The answer is the caller: the principal behind the request, the org, project and env the key is scoped to, and the scopes it carries. Clients read it once at start-up and fill their defaults from it, so a call can name a resource without repeating where it lives.

API

https://api.sylphx.com

Header

Authorization: Bearer <key>

Version

v1, in the path

Errors

Contract routes answer application/problem+json (RFC 9457 style); a few older routes, such as whoami and the organization routes, still answer a plain JSON error body

#Install a client

curl -fsSL https://sylphx.com/install/cli | bash
npm install -g @sylphx/cli
cargo install sylphx-cli --locked

All three talk to the same API with the same key. The CLI is generated from the same schema as the SDKs, so a command and a method are the same call: sylphx data databases list and sylphx.data.databases.list({}) differ only in spelling. Agents and coding assistants covers the MCP server.

#Sign in

1. Run the login

   bashCopy

   sylphx login

2. Approve it in the browser

   The CLI opens sylphx.com/device?user_code=… in your browser with the code already filled in, and waits. Approve the request there, and the key is written to your operating system's keychain — not to a file in the project. The key lives 30 days; run sylphx login again after that. Set SYLPHX_NO_BROWSER=1 to print the link without opening it, and pass --store-file on a machine with no keychain to save the key in the CLI's credentials file instead.

3. Try the first call

   bashCopy

   sylphx access whoami

On a machine with no browser — a build agent, a container, a coding agent — pass an Access key instead of approving one:

sylphx login --api-key -          # the key on stdin
SYLPHX_API_KEY=sylphx_sk_… sylphx data databases list

#How an account is put together

Three things, and only three, decide where a resource lives and who may read it: an organization, a project and an environment.

• Organization — the account. It is created once and billed once. Members and their roles belong to it, so a person joins the organization rather than a project.
• Project — one product's resources, grouped. Most teams run one project per application, and a project is what a repository usually links to.
• Environment — a deployment target inside a project: production, staging, development, or any name you like. Its mode, live or test, decides which keys may touch it, so a test key can never write production data.

Organization

orgs/{org}

Project

orgs/{org}/projects/{project}

Environment

orgs/{org}/projects/{project}/envs/{env}

Everything else hangs below that path: a database, a bucket, a hosting service, a webhook endpoint, an email sender. Accounts and projects has the model in full, and Environments covers modes and where secrets live.

#Keys

A key carries the scopes it is allowed to use. An environment-scoped key acts only in that environment; an organization-wide secret key has no project or environment binding. sylphx login issues an organization-wide key, which can create projects and change project-wide Hosting service definitions when your role allows it. For a machine doing those writes, create an organization-wide key, not an environment-scoped key.

Scopes read <service>:<action> — hosting:read, data:write, secrets:write. A key created for a browser or a mobile app is a publishable key, and it cannot read or write your resources at all.

The secret is shown once, when the key is created or rolled. Send it as Authorization: Bearer <key>.Keys and scopes covers the two kinds, the scope list and rotation.

#Where to go next