Cloud Functions
One handler, three clouds. The same dashboard-authored workload runs as an AWS Lambda, an Azure Function App, or a GCP Cloud Run function — optionally attached to a VPC/VNet so it can reach private resources. Each gets a stable HTTPS endpoint protected by a shared bearer secret. Integration guide.
No functions deployed yet.
Start with echo_diag — it reports what
the function can actually reach from where it landed.
| Name | Workload | Cloud | Network | Status | Actions |
|---|---|---|---|---|---|
Deploy a function
Only regions with a per-region config set are listed — add one under Settings → Multi-region.
Lowercase letters, digits and hyphens — normalised to what all three clouds accept.
This adapter reads its target from its environment and does nothing without
it, so ,
are required here — a deploy that omits them is refused rather
than left for a later job to finish.
To skip this form entirely, use the Function (DB grant) action on
the database's row on the Databases page: that pairing deploys and configures
its own adapter beside the database, in the database's own region.
Still needed:
One KEY=VALUE per line. Non-secret only —
these are stored and logged in cleartext, and a credential-shaped value is refused.
Pass a credential as a secret reference instead.
VPC mode uses the subnet/connector configured in Settings → Cloud Functions. On AWS it also removes the function's internet access unless the subnets route through NAT.
Test invoke
Sends this request with the shared secret attached — the fastest way to tell a broken function from a wrong curl.
Endpoint
What to paste into an Entitle REST integration. Treat the secret like a password.