Dashboard · Screens

Functions

Server-side code that runs on this project's own subdomain. Each function carries a secret key of its own.

Functions are deployed by your agent, which bundles the code on your machine — there is nothing to upload here. The secrets your code reads as env.NAME are set by you, never by your agent: per project in Manage → Secrets, or once for every project on the account's Secrets screen. Click a function to see its details, read its logs, rotate its key or destroy it. How to write one: the edge function guide.

The list#

Each function with its URL and the date its key was created. It reads "Key created", not "Deployed", on purpose: a rotation renews that date. No functions yet? Ask your agent to deploy one — it bundles your code and calls deploy_function.

A function's page#

Overview — the URL, the key id, the key's date, and the secrets actually present on this script — the edge, as it is right now; values are set per project in Manage → Secrets, or for the whole account on the Secrets screen. "No secrets on this script" means none was set for the project or the account, or the fan-out has not reached it yet.

• Rotate secret mints a new key and places it without re-uploading the code; the old one dies with no grace, so the function may see brief 401s while it settles.
• Destroy stops the function from being served and destroys every generation of its key. Your code is not lost — it lives on your machine, and your agent can redeploy this slug in one call. Project secrets are not lost either: a redeploy starts with them.

"This function does not exist (anymore)" — it may have been destroyed; redeploying the same slug brings it back, with the project's secrets.

Logs — the API requests this function made to its own project: the same journal your agent reads with get_logs, filtered on the function's key ids. Execution output (console.log, CPU overruns) is not readable through any tool or screen yet, and invocations themselves are not logged — only the calls its code makes to your project's API. Right after a rotation, a few transient 401s can show up as "Unidentified" entries in the project-wide Logs, not here. If the key ids were not published by the API, the logs cannot be narrowed down: redeploying once (any change) refreshes the record.

Secrets#

Manage → Secrets is where a project secret's value is typed — a key meant for every project is typed once, on the account's Secrets screen. Set once here, a value is readable as env.NAME by every function of this project — including the ones deployed later. Values are set here, by you — never by your agent.

• A value is encrypted at rest and pushed into every deployed function within seconds; it can never be read back — not by us, not by your agent, not on this screen. The Digest column shows the SHA-256 of the value, to compare against what you pasted.
• A name is 1–64 characters, letters, digits and underscores, and your code reads it as env.NAME. The MANYBASES_ prefix is reserved.
• After saving, the screen says how far the value went: "No function deployed yet — the next deployment gets it", "Applied to N function(s)", or "Applied to k/N — retry for: …".
• Remove takes the secret out of the registry and off every function — unless your account shares a secret of the same name: its value goes back on the functions that receive it.
• Below the project's own secrets, Your account's shared secrets lists the account's secrets, read-only, with what each one is in this project: available to its functions, masked by a project secret of the same name (which then says "masks the shared one"), or not injected because its name is reserved. They change on the account's Secrets screen only.
• Deleting a project deletes its secrets.

Your agent writes code that reads env.NAME. It lists the project's secret names first (list_secrets), and the names present on a function (list_function_secrets) to check a value arrived; it can never set or read a value.