Test and deploy from CI
A workable loop from the first edit to an automatic deployment, with the limits of local emulation stated up front.
1. Run it locally
aura functions serve runs your file with Deno and restarts it when you save.
It is a plain Deno server. Compared with the platform, it has:
- No platform headers.
x-aura-roleandx-aura-user-idare absent: send them yourself withcurl -Hto test authorisation branches. - No secrets. Pass them in your shell:
STRIPE_SECRET_KEY=sk_test_… aura functions serve checkout. - No limits. Memory, timeout, body size and rate limits are not applied.
- Plain requests. You call the function directly, so
pathandmethodare those of yourcurl, not the SDK'sinvokeoptions.
The SDK cannot target this server, because invoke calls the platform route. Test the SDK path against a real project, as below.
2. Test it for real
Create a project for development (see your first function), deploy the function there, and test through the SDK. This covers the platform's identity headers, limits and error classes.
Tips:
- Use a dedicated project, never production, and keep its keys in your CI secrets.
- The invocation rate limit is 15 calls then 1 per second per IP. Space your tests, or run them serially.
3. Deploy from CI
The aura CLI installs from npm on macOS Apple Silicon and from source elsewhere, so a Linux CI job is simpler with the HTTP API. Deploying is one POST per function, authenticated with a service_role key. This exact loop was run against a real project and the function answered afterwards.
Facts that make this safe to run on every push:
- The
POSTreplaces the code of an existing function and keeps its secrets, because the body has noenv_vars. - A function is single-file: relative imports are not shipped. Bundle first if you use local modules.
- There is no version history on the server. Your Git history is the rollback: to go back, revert the commit and let CI deploy again.
Then run your integration tests against the project you just deployed, in a following job.
4. Development, staging and production
One project is one environment. Create one project per environment, each with its own URL and keys, and let CI choose the target:
| Environment | Project | Deployed when |
|---|---|---|
| Development | one per developer or shared | on demand, from a branch |
| Staging | my-app-staging | every push to main |
| Production | my-app | a release tag, after the staging tests pass |
Store AURA_PROJECT_URL and AURA_SERVICE_ROLE_KEY per GitHub environment, and set each function's secrets separately in each project. Nothing is shared between projects.