Functions security and limits
A function runs your code on the platform's infrastructure with a caller's permissions, so what the platform does automatically matters as much as what your code does.
Know what the sandbox guards
App-mode code runs in a restricted Python environment on TaruviBase's infrastructure. Two limits apply, and both are about the code, not the network.
The language is restricted. Not every Python construct is available.
BaseException, SystemExit, KeyboardInterrupt, and GeneratorExit are not
among the builtins your code can use, so a function cannot end its own execution
or step outside ordinary exception handling.
Imports are allowlisted. Code may import only the modules listed under
Sandbox imports. Anything
else raises ImportError.
Expect unrestricted outbound access
The allowlist governs which modules load, not what a loaded module may reach.
Permitted modules include requests, httpx, and urllib3. Each provides
outbound network access, so function code can make connections of its own,
including to services on your own network. Database drivers and AWS SDKs are not
allowed; use sdk_client to reach your site's data and storage.
This is intended. stripe, openai, and anthropic are on the allowlist
precisely so functions can call third-party services.
The sandbox limits the Python language, not what your code can reach over the network. Treat function code as you would code running on your own server, and deploy only code you trust.
Proxy functions carry the same responsibility. The destination is whatever URL the function is configured with, so point one only at an endpoint you control or otherwise trust. See Forward a call to a webhook.
Decide deliberately before making a function public
Setting is_public makes a function executable by anyone who can reach its
endpoint, with no credentials.
Permission checks do not apply to a public function. This is deliberate — a function open to anonymous callers is open by definition, so the policy check is skipped for every caller rather than only for unauthenticated ones. A signed-in user whose policy would otherwise deny them can execute a public function.
A public function invoked anonymously runs with the permissions of the user who created it, because an anonymous caller supplies no identity. Whatever that user can reach, the function can reach on a caller's behalf, and if the author's permissions change later the function's capabilities change with them.
Before setting is_public, confirm the code is safe to run with
attacker-supplied parameters. Treat params as untrusted input from the internet
and validate it.
Grant organization access deliberately
Only an organization owner or admin, or another cloud user with access to the site can read, create, change, or delete functions and read their run history. Anyone with that access can change a function's code, destination, and settings, and later callers run whatever the function says at the time. Treat that access as the ability to run anything the site's functions can run, and grant it on that basis.
Review proxy functions and the credentials they store when membership changes.
Scope the credentials a proxy function stores
Proxy functions keep auth_config on the function record, so anyone who can read
that function can read those credentials.
Use a credential scoped narrowly to the integration rather than a general-purpose key, and rotate it when your organization's members change.
Bound every execution
| Boundary | Value |
|---|---|
| Synchronous execution wait | 900 seconds |
| Automatic retries | None — a failed run isn't retried |
| Proxy request timeout | 30 seconds, overridable per function |
| Log entries per execution | 2,000 |
| Log payload per execution | 1 MiB |
| Single log message | 10,000 characters |
These are the current values and may change while Functions is in preview. Log output beyond a threshold is dropped and the log carries a truncation entry, so a log ending in one is incomplete rather than finished.
No concurrency limit, request rate limit, or code-size limit is applied in any layer. Do not design on the assumption that one will stop a runaway function.
Protect execution history before you delete a function
Deleting a function permanently removes its version history, its invocation records, and its schedules. There is no recovery path and no archive.
Export anything you need first, and prefer setting is_active to false when you
want to stop a function running while keeping its history.
Treat execution history as permanent
Every run is recorded, and the records last as long as the function. Organization users with access to the site can read every run's parameters, results, and logs, and a site user can look up a run's result by task id. Nothing you send to a function, return from one, or log inside one should be a secret or personal data.
Where a function must handle sensitive values, read them from Secrets at execution time rather than passing them as parameters.
Share safe diagnostics
When reporting a problem, capture the app and function slugs, the
celery_task_id, the invocation status, and the version that ran. Confirm no
captured log line carries a secret before sharing it.