Functions

Note

Functions are in beta. The feature is live and runs in your own AWS account, but the configuration surface and the way functions are billed may change before general availability. We don’t recommend them for critical production paths yet.

A function is a small serverless handler that runs on demand instead of staying up as a long-lived process. You give Ownkube some code and a trigger, and it runs the code in your own AWS account when the trigger fires. There’s no container to size and nothing running when the function is idle.

Functions are different from the other resource types in one important way: they are cluster-less. A web app, worker, job, or database runs on a cluster. A function attaches directly to an AWS account and region instead, so you can use functions even before you create a cluster.

What you configure

1. Pick a source

   Functions build from a GitHub repository. Connect the GitHub App (see Registries), then pick the repo and branch. Ownkube packages your code into a deployable artifact on each push.

2. Choose a runtime

   Pick the language runtime. Ownkube suggests a default handler for each:

   Runtime	Default handler
   Node.js 24 / 22	index.handler
   Python 3.14 / 3.13	lambda_function.lambda_handler
   Java 25 / 21	example.Handler::handleRequest
   .NET 10	Function::Function.Handler::FunctionHandler
   Ruby 3.4	lambda_function.lambda_handler
   Custom (Go, Rust)	bootstrap

   The handler is the entry point inside your code. The suggestion is editable.

3. Set size and timeout

   Choose the memory (in MB), the timeout (in seconds), and the architecture (x86_64 or arm64). Memory and architecture together decide how much CPU the function gets and what it costs to run.

4. Add a trigger

   Every function needs at least one trigger, HTTP or a schedule (or both). See Triggers.

5. Set environment variables

   Add any KEY=value pairs your handler reads at runtime. They’re stored with the function and injected when it runs.

Triggers

HTTP

An HTTP trigger gives the function its own HTTPS invoke URL. Call the URL and the function runs.

• Auth: leave it open (none) or require AWS IAM signing (iam).
• CORS: configure allowed origins, methods, headers, and max-age for browser callers.

Note

The HTTP invoke URL is issued by AWS for the function. It is not a *.ownkube.app hostname like a web deployment gets. You’ll find the exact URL on the function’s detail page once it’s live.

Schedule (cron)

A schedule trigger runs the function on a recurring cadence. Use a cron(...) expression for calendar-style schedules or a rate(...) expression for fixed intervals. Set an optional time zone (defaults to UTC).

Logs and platform version

• Logs are captured with a configurable retention window, the same way deployments handle logs.
• Functions run on a platform version, like the other resource types. When Ownkube ships a newer version with reliability, performance, and security improvements, the function’s detail page shows an Upgrade control. Staying current is how you pick up new capabilities.

Beta limits

• Functions are gated. You need a connected AWS account before you can create one, and the option may be limited by your plan while in beta.
• Pricing isn’t finalized. Functions don’t yet appear on the pricing page; the billing model for serverless usage is still being worked out.
• GitHub is the only source today. Building from other version-control providers is on the roadmap.

Deployments How functions sit alongside web apps, workers, jobs, and databases.

Registries Connect the GitHub App so Ownkube can build your function.

---

Note

Don’t see a feature you need? Email support@ownkube.io. Ownkube is shaped by the teams using it and we ship what our users ask for.