Moving serverless functions to Open Source Cloud

What maps to Open Source Cloud today

Checked against the live service catalog. Your functions become small HTTP services that run on a runner, deployed straight from a Git repository.

• What you use today: Node.js function behind API Gateway

  On Open Source Cloud: My Apps (Web Runner)

  Put the handler behind a small HTTP server such as Express or Fastify, listening on PORT. Connect the Git repository. No Dockerfile and no build config required.

• What you use today: Python function

  On Open Source Cloud: My Apps (Python Runner)

  Put the handler behind FastAPI or Flask. Both are detected from the repository.

• What you use today: Go function

  On Open Source Cloud: My Apps (Golang Runner)

  Replace lambda.Start with a net/http server on PORT. The rest of your code stays as it is.

• What you use today: .NET function

  On Open Source Cloud: My Apps (.NET Runner)

  Host the handler in an ASP.NET Core minimal API.

• What you use today: Small JavaScript or TypeScript functions

  On Open Source Cloud: lambda (catalog service)

  Zip the code and upload it, and it runs on each HTTP request. The closest fit to one function per endpoint.

• What you use today: Scheduled function (EventBridge rule)

  On Open Source Cloud: My Jobs

  Runs a Python script from a Git repository on a cron schedule. For a schedule in another language, run the timer inside a My App.

• What you use today: SQS queue

  On Open Source Cloud: SmoothMQ

  Describes itself as a drop-in replacement for SQS. Point your SDK at the new endpoint and run the consumer as a My App that polls the queue. Test your calls before you cut over.

• What you use today: S3 bucket

  On Open Source Cloud: MinIO

  S3-compatible API, so the AWS SDK keeps working with a new endpoint and keys. Copy the objects across with S3 Sync.

• What you use today: RDS for PostgreSQL

  On Open Source Cloud: PostgreSQL

  Standard connection string. Import with pg_dump and pg_restore.

• What you use today: ElastiCache for Redis

  On Open Source Cloud: Valkey

  Speaks the Redis protocol, so it is a drop-in. Point your client at the new host.

• What you use today: Environment variables, Parameter Store, Secrets Manager

  On Open Source Cloud: Parameter store

  Values are injected into the app as environment variables when it starts. You move the values, not the API calls.

What changes in the code

The business logic stays. What goes is the event wrapper: a handler that receives an API Gateway event becomes a route that receives an HTTP request.

export const handler = async (event) => {
  const { name } = JSON.parse(event.body);
  return {
    statusCode: 200,
    body: JSON.stringify({ hello: name })
  };
};

import express from 'express';

const app = express();
app.use(express.json());

app.post('/hello', (req, res) => {
  const { name } = req.body;
  res.json({ hello: name });
});

app.listen(process.env.PORT || 8080);

Runs at Elastx in Sweden

Since 25 August 2026, Open Source Cloud runs on Elastx, a Swedish infrastructure provider, in Stockholm. Your functions and their data move to a Swedish provider.

Where OSC runs, who operates it and how you leave

How the move works

What you get

• No cold starts. The process is already running when the request arrives.
• Your code ends up as a plain Node.js, Python, Go or .NET HTTP service, which runs on any host, including your own hardware.
• Every service runs from upstream open source code. No proprietary wrappers or black-box extensions. Audit everything.
• 196+ services, launched from the web, from an API, or from an AI agent over MCP.