How it works
Four steps, no infrastructure to look after
Write one handler
One function that takes a request and returns a response. No Dockerfile and no container configuration.
Connect the repo
Give the git repo address, then pick the runtime and the handler's name. We build your code into an isolated image.
Called through a URL
Your function gets its own address on fn.xpod.dev and its own API key. If the key is lost or leaked, rotate in a new one.
Quiet means free
With no calls there is no bill. Each month includes a free allowance of 1,000,000 calls and 10,000 GB-seconds.
Seven products, one platform
Which one do you need?
The difference is when your code runs: from always on, to not running at all until it is needed.
- What you bring
- An app from the catalog
- When it runs
- Always
- How it is billed
- Monthly
- What you bring
- Your own container image
- When it runs
- Always
- How it is billed
- Monthly, per active minute
- What you bring
- A PostgreSQL database
- When it runs
- Always
- How it is billed
- Monthly
- What you bring
- Static files
- When it runs
- Never
- How it is billed
- Plan + bandwidth
- What you bring
- Code in a container
- When it runs
- On a schedule
- How it is billed
- Per second of execution
- What you bring
- Code or a container
- When it runs
- When messages arrive
- How it is billed
- Per processed message
- XPod Functionsyou are here
- What you bring
- One function (handler)
- When it runs
- When called
- How it is billed
- Per call + GB-second
How billing works
Per call and per GB-second
Free allowance each month
1,000,000 calls and 10,000 GB-seconds. The two allowances are separate: using up one doesn't reduce the other.
Beyond the allowance
Rp0.27 per call, plus Rp0.0432 per GB-second, which is the function's memory (in GB) times how long it runs (in seconds).
Taken from your balance
No card is charged automatically. Charges are taken from your XPod balance; you need at least Rp10,000 to start.
See the pricing details →
Good to know
Before you build on Functions
- The first call can be slower
- A function that hasn't been called for a while has to be started first, so its first call can feel slower than the ones after it.
- Every function has limits
- You set the memory, the time limit and the maximum number of parallel calls for each function. No function runs without a time limit.
- Don't keep state in memory
- Assume any call may be handled by a fresh instance. Keep important data in a database, not in the function's memory.
- Warm instances are optional
- Want to avoid a slow first call? You can keep some instances warm. It is the only Functions charge that runs even with no calls: Rp7,000 per 128 MB of function memory, per warm instance, per month.
- An API key per function
- Each function has its own API key. The full value is shown only when the key is created or rotated, so keep it safe.
- Test calls and monitoring
- From the console you can test a call, see the call history, and read your function's metrics.
When not to use XPod Functions
Functions is not for everything, and that's fine
It has to stay running, or hold a connection
If your process must always be alive, for example to keep a database connection open, use Run.
Go to XPod Run →Long-running tasks
Every function has an execution time limit, so it doesn't suit long processes or big batches. Use Jobs for those.
Go to XPod Jobs →Processing large volumes of queued messages
For work that piles up and must be retried when it fails, Queue is a better fit.
Go to XPod Queue →