> ## Documentation Index
> Fetch the complete documentation index at: https://fissionplane.dev/docs/llms.txt
> Use this file to discover all available pages before exploring further.
# Functions: Deploy Serverless Code on Your Own Hardware
> Deploy versioned functions from OCI images. FissionPlane invokes each from a warm snapshot and scales to zero. Functions are planned for a future release.
Functions are designed to let you deploy code once and invoke it on demand, without managing long-running processes or reserving compute for idle time. You package your handler in an OCI image, deploy it to FissionPlane, and invoke it over HTTPS or on a schedule. Between invocations FissionPlane releases the compute slot entirely — scaling to zero. When a request arrives, a microVM starts from a warm snapshot in milliseconds and runs your handler to completion.
Functions are on the FissionPlane roadmap and are not yet available in the current release (v0.0.1). The design described on this page reflects planned behavior. If you need one-shot isolated execution today, [sandboxes](/docs/concepts/sandboxes) are the right primitive — create a sandbox, run your command, collect the result, and delete it.
Functions and [sandboxes](/docs/concepts/sandboxes) run on the same substrate — the same Firecracker microVMs, the same immutable templates, the same capability token model — but serve different use cases. A sandbox is stateful and interactive: you create it, run a series of commands, and delete it when you're done. A function is deployed once and invoked many times: each invocation is ephemeral and isolated from every other.
## How functions will work
FissionPlane boots your image, runs any setup steps you specify, and snapshots the result as a template artifact. This is the warm snapshot every invocation will start from.
A function deployment binds a handler entry point to a template version. FissionPlane maintains a pool of warm snapshots ready to be restored on demand.
Each invocation restores a microVM from the warm snapshot, runs your handler, and returns the result. The microVM is released when the handler exits. The next invocation gets a fresh environment.
Because each invocation starts from the same snapshot, your handler always sees the same initial filesystem and process state. Side effects from one invocation never bleed into the next.
## Planned API shape
The examples below illustrate the intended API. These methods are not available in v0.0.1.
### Deploying a function
```ts TypeScript theme={"theme":{"light":"github-light","dark":"github-dark-default"}}
const fn = await client.functions.deploy({
image: 'ghcr.io/your-org/my-handler:v1.2.0',
name: 'data-processor',
handler: 'index.handler',
})
console.log('Deployed function:', fn.functionId)
```
```python Python theme={"theme":{"light":"github-light","dark":"github-dark-default"}}
fn = client.functions.deploy(
image="ghcr.io/your-org/my-handler:v1.2.0",
name="data-processor",
handler="index.handler",
)
print("Deployed function:", fn.function_id)
```
### Invoking a function
```ts TypeScript theme={"theme":{"light":"github-light","dark":"github-dark-default"}}
const response = await client.functions.invoke('data-processor', {
payload: { input: 'some data' },
})
console.log(response.result)
```
```python Python theme={"theme":{"light":"github-light","dark":"github-dark-default"}}
response = client.functions.invoke(
"data-processor",
payload={"input": "some data"},
)
print(response.result)
```
### Scheduling functions
```ts TypeScript theme={"theme":{"light":"github-light","dark":"github-dark-default"}}
await client.functions.schedule('data-processor', {
cron: '0 2 * * *', // Every day at 02:00 UTC
})
```
```python Python theme={"theme":{"light":"github-light","dark":"github-dark-default"}}
client.functions.schedule(
"data-processor",
cron="0 2 * * *", # Every day at 02:00 UTC
)
```
### Versioning and rollback
Every deployment creates a new version. Versions are immutable: deploying new code does not change existing versions. You can roll back to any previous version with a single call.
```ts TypeScript theme={"theme":{"light":"github-light","dark":"github-dark-default"}}
// List versions of a function
const versions = await client.functions.listVersions('data-processor')
// Roll back to a specific version
await client.functions.setActive('data-processor', { version: versions[1].versionId })
```
```python Python theme={"theme":{"light":"github-light","dark":"github-dark-default"}}
# List versions of a function
versions = client.functions.list_versions("data-processor")
# Roll back to a specific version
client.functions.set_active("data-processor", version=versions[1].version_id)
```
## Intended use cases
Put your handler behind a stable HTTPS endpoint. FissionPlane scales it down to zero between requests and back up in milliseconds when traffic arrives.
Run functions on a cron schedule. Each execution gets a clean, isolated microVM — no accumulated state, no dependency on previous runs.
Fan out work across many function invocations in parallel. Each runs in isolation and exits when complete.
Wire up a function to any HTTPS webhook. Handle events without maintaining a long-running service.
## What to use today
Until functions ship, [sandboxes](/docs/concepts/sandboxes) cover the one-shot execution pattern well. Create a sandbox, run your command, collect the result, and delete it. The latency is slightly higher than a pre-warmed function invocation, but the isolation guarantees are identical — the same Firecracker microVM, the same hardware boundary.