Forem: Jonas Birmé

Run Claude Code Agents on a Schedule in the Cloud

Jonas Birmé — Wed, 15 Apr 2026 13:12:23 +0000

You use Claude Code locally. It reviews code, writes tests, debugs problems. You close the laptop and the work stops.

What if it kept going?

My Agent Tasks is a new feature in Open Source Cloud (OSC) that lets you schedule Claude Code to run autonomously in the cloud, on your repositories, on a cron schedule, without your machine being on. Daily code reviews, automated health checks, weekly dependency audits, scheduled deployment reports. You define the task once. The agent does the work.

I built this on top of claude-runner, an open source service I developed that runs headless Claude Code sessions as one-shot jobs in containers. The scheduling layer, credentials management, and web UI shipped on April 14, 2026 as My Agent Tasks in the OSC console.

Everything is open source. No proprietary agent runtime, no black-box infrastructure.

What this is for

Claude Code in your IDE is interactive: you type, it responds, you iterate. That model is great for active development sessions. It breaks down for anything that should happen automatically.

Consider the tasks you actually want running on a schedule:

Review the src/ directory for new security issues every morning
Check that deployed services are healthy after each release
Generate a weekly summary of what changed and why
Update a docs file whenever the codebase drifts from it
Post a Slack report after a nightly batch job completes

None of these need you at the keyboard. They need an agent with access to your code, the right prompt, and a timer.

My Agent Tasks is that timer, attached to that agent, running in the cloud.

Prerequisites

Before you start, you need:

An OSC account on a paid plan (Personal, Professional, or Business). The free tier does not include scheduled tasks.
A git repository, either public or private (HTTPS URL required)
An Anthropic API key

Step 1: Get your authentication credentials

Get an API key from console.anthropic.com. Navigate to API Keys, create a new key, and copy the value.

This is standard Anthropic API billing: you pay per token consumed by each task run.

Step 2: Navigate to My Agent Tasks

Open https://app.osaas.io/dashboard/agent-tasks.

The first time you visit, OSC prompts you to configure your credentials. Enter your token (OAuth or API key) and click Save. The credentials are stored in Kubernetes Secrets on the platform, never exposed in API responses or logs.

Once saved, you land on the task list, which is empty until you create your first task.

Step 3: Create your first task

Click "Create Task". You will see a form with several fields.

Walk through them:

Name

A short identifier with no spaces. This becomes part of the job name in the system. Example: code-review, daily-health, docs-sync.

Description

A plain English description of what this task does. For your own reference.

Prompt

This is the instruction Claude receives. Write it the same way you would write a CLAUDE.md prompt or a Claude Code session opener. Be specific about what you want done and where results should go.

Example prompt for a code review task:

Review the code in src/ for potential bugs, security issues, and code quality problems.
Focus on: unhandled errors, SQL injection, authentication flaws, and logic errors.
Write a summary of findings to review.md. If no issues are found, write "No issues found" with the date.

Source URL

The HTTPS URL to your git repository. Supports a branch suffix with #:

https://github.com/myorg/myrepo
https://github.com/myorg/myrepo#main
https://github.com/myorg/myrepo#staging

Schedule

OSC provides presets for common schedules:

Preset	Cron expression
Every 15 minutes	`/15 * * *`
Hourly	`0 * * * *`
Daily at 9am	`0 9 * * *`
Weekdays at 9am	`0 9 * * 1-5`
Weekly Monday at 9am	`0 9 * * 1`

You can also enter any valid cron expression directly for custom schedules.

Advanced settings

Expand the advanced panel for these options:

Model

Defaults to claude-sonnet-4-5-20250514. Change this if you want a different Claude version. Use a less capable model for simple tasks to reduce token usage.

Max Turns

Defaults to 25. This is how many back-and-forth steps Claude can take in a single run. For straightforward tasks like "generate a report", 10 is plenty. For complex tasks involving multiple files and tool calls, raise it. Higher values cost more tokens.

Allowed Tools / Disallowed Tools

By default Claude has access to all standard tools: file read/write, bash execution, web fetch. Restrict this for safety.

For read-only analysis runs, add Edit,Write,Bash to Disallowed Tools. The agent can read files and produce output but cannot modify anything.

For tasks that only need to inspect code:

DisallowedTools: Edit,Write,Bash

For tasks that should write files but not run code:

DisallowedTools: Bash

Sub Path

If your repository is a monorepo, set this to the subdirectory where Claude should work. Example: packages/backend or apps/web. Claude's working directory will be set to this path.

Git Token

For private repositories, provide a GitHub Personal Access Token (or equivalent). Stored as a Kubernetes Secret.

To reference a stored secret instead of a raw token value:

{{secrets.mygithubtoken}}

See the section on the CLI below for how to store secrets this way.

OSC Access Token

Required only if your task needs to manage OSC services from within the agent session. For example, a task that provisions a new service instance or queries the catalog. This enables MCP integration from within the task. Leave empty for tasks that only touch your repository.

Step 4: Run and monitor

After saving, your task appears in the list with its schedule and status.

Run Now: Triggers an immediate execution without waiting for the next scheduled time. Useful for testing your task before relying on the schedule.

Last Run / Next Run: Shows when the task last executed and when it is scheduled to run next. The scheduler polls every 60 seconds, so the next run timestamp is accurate within a minute.

Edit / Delete: Standard task management. Editing a task takes effect on the next scheduled run.

To see what happened during a run, check the logs for the underlying claude-runner job instance. You can find these in the OSC service catalog under the birme-claude-runner service, or query via the CLI.

Using the CLI

If you prefer to manage tasks from the terminal, the OSC CLI exposes the underlying claude-runner service directly.

Install and authenticate:

export OSC_ACCESS_TOKEN=<your-osc-token>

Create a job:

npx -y @osaas/cli create birme-claude-runner codereview \
  -o AnthropicApiKey="{{secrets.anthropicapikey}}" \
  -o SourceUrl="https://github.com/myorg/myrepo" \
  -o Prompt="Review the code in src/ for potential bugs and security issues. Write a summary report to review.md." \
  -o MaxTurns="10"

The {{secrets.name}} syntax tells the runner to pull the value from your stored secrets at runtime, rather than embedding credentials in plain text in the job definition.

Store a secret first using the web console or via the CLI. Then reference it with {{secrets.anthropicapikey}} in any job option. This applies to git tokens, API keys, Slack webhook URLs, and any other sensitive value you need injected at runtime.

Using MCP tools for an AI-native workflow

If you have the OSC MCP server connected to Claude or another MCP-compatible tool, you can manage agent tasks through natural language:

Create a daily task called sync-report that runs every weekday at 9am.
It should clone https://github.com/myorg/myrepo and run:
"Generate a daily standup summary from git log since yesterday.
Write it to standup.md."

List my agent tasks

Run my code-review task now

The MCP server maps these requests to dedicated agent task tools: setup-agent, create-agent-task, list-agent-tasks, run-agent-task, and delete-agent-task. You are managing cloud infrastructure through conversation, without touching the UI or CLI at all.

The OSC MCP endpoint is https://mcp.osaas.io/mcp. Connect it from Claude Desktop, Cursor, or any MCP-compatible client.

Injecting environment variables with a parameter store

Some tasks need credentials beyond the git token and Claude auth: a Slack API token, a webhook URL, a database connection string. You do not want these hardcoded in your prompt or repository. OSC solves this with a parameter store (the Application Config Service).

When you set the Config Service field on a task, Claude Runner loads all key-value pairs from that parameter store and injects them as environment variables before the session starts. Your prompt can then reference them naturally, and any Bash commands Claude runs will have access to them.

Setting it up

1. Create a parameter store

You can do this through the OSC web console, the CLI, or via MCP. Using the CLI:

npx -y @osaas/cli create eyevinn-app-config-svc myagentconfig \
  -o RedisUrl="<your-valkey-url>"

Or use the setup-parameter-store MCP tool which creates both the Valkey instance and the config service in one step.

2. Add your environment variables

Store the keys your task needs. For example, a Slack token:

curl -X PUT "https://<your-config-svc-url>/api/v1/config/EYEVINN_SLACK_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"value": "xoxb-your-slack-bot-token"}'

Add as many keys as you need. Each one becomes an environment variable in the runner container.

3. Reference it in your task

When creating or editing a task, set the Config Service field to the name of your parameter store (e.g., myagentconfig). You also need an OSC Access Token set, since the runner uses it to read the parameter store at startup.

Now your prompt can reference the injected variables. Here is a real example I use for scheduled deployment updates with Slack notifications:

Prompt:

Restart myapps intercom, mediaconvert, analytics, opensubtitlesite so it
fetches latest code. Post to slack channel #osaas-agents using the
environment variable EYEVINN_SLACK_TOKEN when done.

The agent restarts the apps using OSC MCP tools, then posts a summary to Slack using the token that was injected from the parameter store. No credentials in the prompt, no secrets in the repository.

This pattern works for any external service: post to Discord, update a Notion page, trigger a webhook, write to a database. Store the credentials in the parameter store, reference them in the prompt by environment variable name.

Practical use cases

Here are four patterns that work well with My Agent Tasks.

Automated code review

Schedule: Weekdays at 7am, before standup

Max Turns: 15

Prompt:

Review the diff since yesterday (use git log and git diff). Look for:
- Obvious bugs or unhandled edge cases
- Missing error handling
- Security issues (injection, auth flaws, hardcoded secrets)
Write a concise review to daily-review.md with severity labels: INFO, WARNING, CRITICAL.

This gives your team a morning code review without a human having to do it.

Scheduled deployment health check

Schedule: Every hour

DisallowedTools: Edit,Write

OSC Access Token: set

Prompt:

Check the status of my OSC services using the available MCP tools.
For each service that is not healthy, list the service name and error.
Output the result to stdout as a JSON object with keys: healthy, degraded, failed.

With an OSC Access Token set, the agent can call OSC MCP tools from inside the task to query your live service instances.

Daily dependency audit

Schedule: Weekly Monday at 8am

Max Turns: 20

Prompt:

Run npm audit (or equivalent for this project) and check package.json for outdated dependencies.
Produce a report in audit.md listing: critical vulnerabilities, high vulnerabilities, and packages more than 2 major versions behind.
For each critical finding, suggest the upgrade command.

Read-only analysis with restricted tools

For tasks where you want analysis only with no risk of the agent modifying your codebase:

DisallowedTools: Edit,Write,Bash

Prompt:

Analyze the TypeScript types in src/types/ and identify any patterns that suggest missing null checks, incorrect return types, or overly broad any usage.
Output a type safety summary to stdout listing each finding with file path and line number.

With Bash disabled and Edit/Write disabled, the agent reads files and reasons about them. Nothing runs. Nothing changes. Safe to run against production codebases.

How it works under the hood

The claude-runner service clones your repository into an ephemeral container, then runs Claude Code non-interactively with your prompt and configuration. The container has a full file system, network access (controlled by your tool settings), and the Claude Code runtime.

The scheduler in OSC checks tasks every 60 seconds and spawns a new job container when a task is due. Each run is isolated: previous run state does not carry over unless your task explicitly reads output files committed back to the repo.

Credentials are stored as Kubernetes Secrets in the platform namespace. They are never returned in API responses, never logged, and never included in job definitions as plain text.

The runner, the scheduler, and the platform infrastructure are all open source. No proprietary agent runtime sits between you and Claude.

Preparing your repository for agent tasks

The quality of the agent's output depends heavily on the context it has. Before relying on scheduled tasks, invest a few minutes in your repository's context files.

Add a CLAUDE.md file

This is the most important thing you can do. CLAUDE.md is loaded by Claude Code at the start of every session. Put in it:

What this project does (one paragraph)
Tech stack and key dependencies
How to run tests
Common patterns and conventions specific to your codebase
Things Claude should NOT do (e.g., "never commit directly to main")

# my-api

A REST API built with Node.js, Express, and Postgres.

## Testing
npm test - runs the full test suite
npm run test:unit - unit tests only

## Conventions
- All errors must be wrapped in AppError class
- Never use any TypeScript type
- Database queries go in src/db/, never inline in routes

Add .claude/settings.json for tool restrictions

You can set default tool restrictions at the repo level rather than configuring them per task:

{
  "disallowedTools": ["Bash"]
}

This acts as a safety baseline for all agent tasks targeting this repository.

Use sub-path for monorepos

If your repo has multiple packages, set the Sub Path field to direct the agent to the relevant package. The agent's working directory will be scoped to that path.

This is agentic engineering

There is a shift happening from vibe coding (AI in your IDE, you direct everything interactively) to agentic engineering, where agents run autonomously on schedules, performing real work independently.

The difference is not the capability of the model. It is where the agent lives and when it runs. An agent that only runs when you are at the keyboard is a powerful tool. An agent that runs on a schedule, in the cloud, with access to your repositories and infrastructure, is a colleague.

My Agent Tasks makes the second thing practical to set up.

Every component that makes this work is open source: the claude-runner service, the web runners, the scheduler, the OSC platform itself. When you schedule an agent task on OSC, you are not locked into any proprietary runtime or vendor-specific agent format. You can inspect, modify, or self-host every layer.

Get started

The My Agent Tasks interface is at https://app.osaas.io/dashboard/agent-tasks.

Documentation is at https://docs.osaas.io.

If you want to talk to other developers building on OSC, the community Slack is at https://slack.osaas.io.

Start with a read-only task: pick a repository, set DisallowedTools to Edit,Write,Bash, write a prompt that produces a report file, and run it manually first. Once you have output you trust, turn on the schedule.

Open Source Cloud provides 200+ open source projects as managed services with native MCP integration. Every component is open source, zero vendor lock-in. Revenue is shared with the creators of the open source projects that power the platform.

Own Your Bluesky Identity: Self-Host a PDS on Open Source Cloud

Jonas Birmé — Mon, 16 Mar 2026 13:12:42 +0000

Own Your Bluesky Identity: Self-Host a PDS on Open Source Cloud

Your Bluesky account lives on a server you don't control. When Bluesky the company makes decisions about that server, you inherit them. The AT Protocol was designed to fix this — your identity is a DID (decentralized identifier) that can be anchored to a server you run. But most people never self-host because standing up a Personal Data Server is too much work.

This guide gets you a running PDS in about five minutes. No Kubernetes experience required.

Why it matters

Your PDS is more than storage. It's the root of your AT Protocol identity. When your account lives on bsky.social, your DID resolves through Bluesky's infrastructure. When you self-host, your DID resolves through yours. You can migrate back to bsky.social or to any other PDS at any time — the AT Protocol guarantees portability. But you're never dependent on one company's availability or policies.

For developers especially: a self-hosted PDS lets you experiment with the AT Protocol directly, create accounts for testing, and build on infrastructure you understand end to end.

What you'll need

An account on Open Source Cloud (free tier works)
A terminal (for the PDS admin steps)

That's it. OSC handles the container, TLS, and DNS automatically.

Step 1: Create the PDS instance

There are two ways to spin up a PDS on OSC.

Option A: Use the web console

Log in to app.osaas.io, find Bluesky Personal Data Server in the service catalog, and click Create. Fill in a name and an admin password. That's it — OSC provisions the container, TLS certificate, and DNS record for you.

Option B: Use an AI agent via MCP

Connect the OSC MCP server to Claude, ChatGPT, or any MCP-compatible AI tool. Then just tell it:

Create a bluesky-social-pds instance named "mypds" with admin password "choose-a-strong-password"

The agent calls the create-service-instance tool and hands you back a running URL.

Either way, you'll get an instance URL in the pattern:

https://{tenant}-mypds.bluesky-social-pds.auto.prod.osaas.io

Hold onto that URL — it's your PDS hostname for every step below.

Step 2: Verify it's running

The PDS exposes a health endpoint. Give it 30 seconds to start, then:

curl https://YOUR_PDS_URL/xrpc/_health

You should see:

{"version":"0.4.208"}

If you get a connection error, wait another 30 seconds. The container is still starting.

You can also check what domains and features the server advertises:

curl https://YOUR_PDS_URL/xrpc/com.atproto.server.describeServer

This returns the server DID, available user domains, and whether invite codes are required (they are, by default).

Step 3: Create an invite code

The PDS requires an invite code to create accounts. This is an admin-only operation.

curl -X POST \
  -H "Authorization: Basic $(echo -n 'admin:YOUR_ADMIN_PASSWORD' | base64)" \
  -H "Content-Type: application/json" \
  -d '{"useCount": 1}' \
  https://YOUR_PDS_URL/xrpc/com.atproto.server.createInviteCode

Replace YOUR_ADMIN_PASSWORD with the password you set in Step 1.

The response looks like:

{"code":"mypds-abcd1234-xyz"}

Save that code — you'll need it in the next step. Set useCount higher if you want the same code to work multiple times.

Step 4: Create your account

curl -X POST \
  -H "Content-Type: application/json" \
  -d '{
    "email": "you@example.com",
    "handle": "yourname.YOUR_PDS_HOSTNAME",
    "password": "your-account-password",
    "inviteCode": "mypds-abcd1234-xyz"
  }' \
  https://YOUR_PDS_URL/xrpc/com.atproto.server.createAccount

The handle follows the pattern username.your-pds-hostname — for example:

alice.mytenant-mypds.bluesky-social-pds.auto.prod.osaas.io

The response includes your DID, handle, and access tokens:

{
  "did": "did:plc:...",
  "handle": "alice.mytenant-mypds...",
  "accessJwt": "...",
  "refreshJwt": "..."
}

Your DID is your permanent identity on the AT Protocol. The handle is how people find you.

Step 5: Log in from the Bluesky app

Open the Bluesky app (iOS, Android, or web at bsky.app).

On the sign-in screen, look for "Advanced" or "Hosting provider" — the exact label varies by app version. Enter your PDS URL as the hosting provider:

https://YOUR_PDS_URL

Then sign in with the handle and password you created in Step 4. The app will connect to your PDS directly.

Optional: Use a custom domain

The default hostname is readable but not exactly elegant. If you own a domain, you can map it to your PDS and use handles like alice.yourdomain.com.

Two things need to happen:

1. Add the custom domain in OSC

In the web console, go to My Apps and add a custom domain for your PDS instance (e.g., pds.yourdomain.com). You can also do this via MCP — ask your AI agent to add a custom domain for your PDS instance. This tells OSC to provision a TLS certificate and route traffic for that domain to your instance.

2. Point DNS to OSC

Add a CNAME record in your DNS provider pointing pds.yourdomain.com to your instance's auto-generated hostname. Once DNS propagates and the TLS certificate is issued, your PDS is reachable at the custom domain.

When creating the PDS instance, set the DnsName field to your custom domain so the PDS knows its public hostname. Handles on your PDS then become username.pds.yourdomain.com.

You can also configure SMTP for sending verification emails by setting the EmailSmtpUrl and EmailFromAddress fields when creating the instance.

What's next: migrate your existing account

If you already have a Bluesky account on bsky.social, you can migrate it to your PDS. The AT Protocol supports account migration — your DID stays the same, your follows and followers transfer, and your existing posts remain accessible. The migration process is documented in the AT Protocol specs and Bluesky has a migration tool in their settings.

You don't have to do this immediately. Your new self-hosted account and your bsky.social account can coexist.

The infrastructure should be simple

Running your own PDS used to mean setting up a VPS, installing Docker, managing volumes, dealing with TLS, and hoping nothing breaks on Saturday night. That friction is why most people never do it.

The Bluesky PDS is available on Open Source Cloud because it belongs there — alongside Postgres, Valkey, MinIO, and 160+ other open source projects, all running as managed services. No configuration overhead, no infrastructure babysitting.

The AT Protocol's bet is that social media built on open protocols is more durable than any single platform. The infrastructure underneath that bet should be just as open and just as easy to run.

Open Source Cloud provides open source software as managed services. The Bluesky PDS is one of 160+ services available — all open source, no vendor lock-in.

How to Deploy Your Vibe-Coded App to Production with Claude + OSC MCP

Jonas Birmé — Wed, 11 Mar 2026 09:36:22 +0000

Vibe-coded apps built with Claude Code, Cursor, or Windsurf deploy to production in under 5 minutes using the OSC MCP server. Connect your AI agent once, then deploy databases, app hosting, and 200+ open source services through natural language — no Kubernetes, no cloud config. The agent that wrote your app can also ship it. You just need to give it the right infrastructure tools.

This is the gap vibe coding exposed: the build is instant, the deploy is not. Claude can scaffold a full-stack app with a Postgres-backed API and authentication in under 10 minutes. Then you spend the next hour provisioning the database, setting environment variables, wiring the connection strings, and debugging TLS. The creative work automated, the mechanical work manual. Open Source Cloud (OSC) closes that gap by giving your AI agent direct access to infrastructure tools through MCP.

What is vibe deployment?

Vibe deployment is the natural extension of vibe coding: you let the same AI agent that built your app also ship it. Instead of stopping at "here's your code," the agent provisions the database, deploys the application, sets the environment variables, and hands you a live URL — all in the same conversation. The infrastructure decisions happen through tool calls, not through config files you write and run yourself.

The term is new, but the idea is straightforward: if an agent can write the code, it should be able to run it too.

Prerequisites

One command. That's it.

For Claude Code, run:

claude mcp add --transport http osc https://mcp.osaas.io/mcp

The first time you use an OSC tool, Claude Code will open a browser window for OAuth authentication. If you don't have an OSC account yet, you can create one there — no separate signup step required.

For Claude Desktop, Cursor, Windsurf, and other MCP-compatible tools, the OSC MCP page has one-step connection instructions for each.

Step-by-step: deploy a vibe-coded app via Claude Code

Say you've built a Node.js app with a PostgreSQL backend during a vibe coding session. Your agent wrote the code. Now you want it live. Here's how the conversation goes.

Step 1: Ask the agent to provision a database

You: I need a PostgreSQL database for this app. Can you provision one on OSC?

The agent calls the OSC MCP create-service-instance tool with serviceId: "eyevinn-postgres". Within about 30 seconds, it gets back a connection string using the instance's port-mapped host and port:

Agent: Done. Your PostgreSQL instance is running.
Connection string: postgres://user:password@<host>:<port>/myapp
I've stored it in the OSC parameter store under "DATABASE_URL".

Step 2: Deploy the app

You: Now deploy the app. Source is github.com/yourname/your-app

The agent calls create-myapp with your GitHub repo URL and attaches the parameter store containing DATABASE_URL:

Agent: Deploying from github.com/yourname/your-app...
Build complete. Your app is live at:
https://yourapp-abc123.apps.osaas.io

Step 3: Wire a custom domain (optional)

You: Map it to api.myproject.com

The agent calls the domain-mapping tool, creates the DNS record, and Let's Encrypt TLS is provisioned automatically.

Step 4: Verify it's running

You: Check the app status and show me the last 20 lines of logs

The agent queries the instance health and fetches logs — no terminal, no cloud console, no context switch.

Step 5: Done

From "I need a database" to a live, TLS-terminated, custom-domain app: four exchanges. The agent handled every infrastructure decision. You stayed in the conversation.

What you can deploy

OSC exposes 200+ open source services through MCP. The categories your agent can provision in a single session:

Databases
PostgreSQL, MariaDB, CouchDB, ClickHouse, MongoDB, MySQL — all fully managed, all open source.

Caching and queues
Valkey (Redis-compatible), SmoothMQ (SQS-compatible). One tool call, connection string back.

Storage
S3-compatible object storage (MinIO). Your agent can create a bucket, get credentials, and wire them to your app without leaving the conversation.

App hosting
Deploy any GitHub repo running Node.js, Python, or WASM. Environment variables wired via the OSC parameter store. Custom domains with automatic TLS.

Intelligence
The OSC Architect tool — an AI that helps your agent design multi-service architectures before it starts provisioning. Ask it to plan before you build.

The full catalog: osaas.io/mcp.

No lock-in — take your code anywhere

Other platforms deploy to their infrastructure. You write your app against their APIs, their managed runtimes, their proprietary services. When agents make infrastructure decisions at speed, you can end up locked into vendors you didn't consciously choose.

OSC deploys to open source. Every service your agent provisions is an open source project:

PostgreSQL is actual PostgreSQL
Storage is MinIO-compatible S3
Caching is Valkey — the Redis fork maintained by the Linux Foundation
App hosting runs on open source container runtimes

That means you can take any component — or the entire stack — and run it yourself on AWS, GCP, bare metal, or your own Kubernetes cluster. The connection strings work the same. The data is yours.

When your AI agent is making infrastructure choices for you, open source is your insurance policy.

What this looks like at scale

The production benchmark: Streaming Tech TV+, a streaming platform built in 36 hours by one developer directing 6 AI agents. 15,000+ lines of code, 99 commits, 13 OSC services in the final stack — PostgreSQL, two Valkey caches, MinIO, video transcoding, HLS packaging, Whisper subtitles, ClickHouse analytics. The agents didn't just write code. They provisioned every service and wired every connection.

That's the endpoint. Your next vibe coding session is the starting point.

Try it

Run claude mcp add --transport http osc https://mcp.osaas.io/mcp (or connect your tool of choice)
Authenticate via OAuth — account creation is part of the flow if you're new
Start a new session, ask your agent to build and deploy something

The next time you vibe code an app, you don't have to stop when the code is done.

Open Source Cloud provides 200+ open source projects as managed services with native MCP integration. Every component is open source — zero vendor lock-in. Revenue is shared with the creators of the open source projects that power the platform.

Infrastructure-as-Code Was Built for Humans. AI Agents Need Infrastructure-as-Tools.

Jonas Birmé — Wed, 04 Mar 2026 15:48:12 +0000

Infrastructure-as-Code Was Built for Humans. AI Agents Need Infrastructure-as-Tools.

Last week I watched a Claude agent write a complete Next.js app with a Postgres-backed API, authentication, and tests. Took about 8 minutes. Then it said "here's your code" and I spent the next hour manually provisioning the database, configuring the deployment, setting environment variables, and debugging TLS.

The agent did the creative, hard work. I did the mechanical, boring work. Something is backwards here.

This isn't about agents getting smarter. It's about infrastructure not speaking their language yet.

The gap nobody's solving

Look at the last mile of every AI coding session:

Agent writes the code (automated)
You provision a database (manual)
You set up hosting (manual)
You configure a domain + TLS (manual)
You wire environment variables (manual)
You deploy and debug (manual)

Steps 2-6 aren't creative work. They're mechanical, repetitive, and well-defined — exactly the kind of tasks agents are good at. But agents can't do them because infrastructure tools weren't designed for tool-calling.

Terraform assumes a human writes HCL files, runs terraform plan, reviews the diff, runs terraform apply, and manages state files. Pulumi assumes you're writing a program. Even cloud CLIs assume you're typing commands in a terminal.

An agent doesn't want to write a Terraform file. It wants to call create-database and get a connection string back.

What agent-native infrastructure looks like

At Open Source Cloud, we've built what we think this layer should be: infrastructure exposed as MCP tools.

MCP (Model Context Protocol) is the open standard for giving AI agents access to external tools. It's already baked into Claude, ChatGPT, Cursor, Copilot, Windsurf, and most AI coding assistants. When you connect our MCP server, the agent gets 40+ tools for provisioning real infrastructure:

Databases: Postgres, MariaDB, CouchDB, ClickHouse, Valkey (Redis-compatible)
Storage: S3-compatible object storage buckets
Applications: Deploy any Git repo (GitHub, Gitea, GitLab) as a running service
Configuration: Parameter stores, secrets management, environment variables
Domains: Custom domain mapping with automatic TLS via Let's Encrypt
Intelligence: An OSC Architect AI that helps design multi-service architectures

Each tool is a single function call with structured JSON input/output. No config files. No state management. No plan/apply cycle.

Agent: "I need a Postgres database for the user service"
→ calls create-database(type: "postgres", name: "userdb")
→ gets back: { url: "postgres://...", port: 5432, status: "running" }
→ stores the connection string in a parameter store
→ deploys the app with the parameter store attached

Four tool calls. The agent doesn't need to know what Kubernetes is.

"But Vercel and Railway have MCP servers too"

They do. And you should look at what those MCP servers actually expose.

Vercel's MCP server lets your agent read logs, inspect project metadata, and browse documentation. Railway's lets you query metrics and manage environments. These are useful, but they're read-only — dashboard operations wrapped in a protocol.

OSC's MCP server exposes write operations. Create a database. Deploy an application. Provision storage. Wire a domain. Set a secret. Your agent doesn't just monitor your infrastructure — it builds it.

That's the difference between giving an agent a window and giving it a workbench.

From 36 hours of agents to production

This isn't a thought experiment. Streaming Tech TV+ is a production streaming platform built in 36 hours by one developer (Jonas Birme) directing 6 AI agents. The architecture:

2 Claude Opus 4 agents: team lead + architect
1 Claude Opus 4 agent: UX designer
3 Claude Sonnet 4 agents: backend, frontend, QA

13 OSC services in the final stack: PostgreSQL, two Valkey caches, MinIO object storage, video transcoding (SVT Encore), HLS packaging, auto-generated subtitles (Whisper), ClickHouse analytics, plus the app frontends and backends.

15,000+ lines of code. 76 files. 99 commits. ~150 agent-hours of work.

The agents didn't just write code. They provisioned databases, created storage buckets, deployed services, and wired event pipelines. The human directed the architecture. The agents handled everything else — including infrastructure.

Other community examples show the same pattern across different domains: a CRM (SpecterCRM), a social reading platform (PageTurner), an audio social network (VoiceCircle), an RSS curation pipeline, a gaming activity tracker. All built with AI assistance, all deployed on OSC infrastructure.

Why open source is non-negotiable for agent-provisioned infra

Here's a scenario that should worry you: your agent spins up three proprietary managed services during a conversation. You didn't explicitly choose those vendors — the agent picked what was available. Six months later, you realize you're paying 3x what you expected and migration means rewriting your data layer.

On OSC, every service is open source. Postgres is actual Postgres. Storage is MinIO-compatible. Caching is Valkey (the Redis fork). Your Next.js app runs on an open source web runner container. You can take any component — or the whole stack — and move it to AWS, GCP, bare metal, or your laptop.

When agents make infrastructure decisions at speed, open source is your safety net. Not a philosophical preference — a practical one.

The infrastructure-as-code to infrastructure-as-tools shift

Infrastructure-as-code was the right abstraction for human developers. Declarative files. Version control. Code review. Plan/apply. It fits how humans think about systems.

Agents think differently. They need:

Immediate feedback: Call a tool, get a result in seconds. Not "write a file, run a command, wait for convergence, parse the output."
Atomic operations: One tool does one thing. Not "here's a 200-line manifest that creates 15 resources and might partially fail."
Structured I/O: JSON in, JSON out. URLs, connection strings, status codes. Not log streams to regex-parse.

This doesn't mean IaC goes away — it's still the right choice for version-controlled, team-reviewed infrastructure changes. But there's a new layer emerging on top: one that speaks the agent's language while orchestrating the same underlying infrastructure. The Terraform MCP server is one approach (wrapping IaC in tool calls). OSC takes a different approach: the tools are the infrastructure API directly, no IaC intermediary.

What this changes

When agents can provision infrastructure natively, development workflows shift:

Prototyping becomes a conversation. "Build me a REST API with a Postgres backend and deploy it" goes from a day of setup to a 5-minute chat.

The feedback loop collapses. Agent writes code → deploys → hits an error → reads logs → fixes → redeploys. No human in the loop for the mechanical steps.

Full-stack is the default. When a database is one tool call away, there's no reason for an agent to stop at "here's your code, now go set up a database yourself."

The barrier drops to intent. If you can describe what you want, an agent can build and deploy it. The infrastructure knowledge lives in the tools, not in your head.

Try it

Connect the OSC MCP server to Claude Desktop, Cursor, Copilot, or any MCP-compatible tool. Then don't ask it to "write code for" something. Ask it to build something. Database, backend, frontend, deployed, live.

The free tier is enough to test the full workflow.

I let my AI agent deploy a Next.js app and it actually worked

Jonas Birmé — Mon, 02 Mar 2026 14:05:15 +0000

I've been using Claude and Cursor to write code for a while now. The part that always annoyed me was the handoff. The agent writes the app, then I alt-tab to some dashboard, click through a deploy wizard, set up a database in another tab, configure env vars somewhere else. The agent did the interesting work. I got the chores.

So I tried something different: I connected an MCP server to Claude that has actual infrastructure tools — not just "read your logs" tools, but tools that create databases, deploy apps, set up domains. The MCP server is from Open Source Cloud, and the tool I cared about was create-my-app.

The deploy

Here's the literal prompt I used:

Deploy my Next.js app from https://github.com/myuser/my-app
as a Node.js app called "myapp"

The agent called create-my-app. OSC pulled the repo, detected Next.js, built it, deployed it to Kubernetes, and gave me an HTTPS URL at *.apps.osaas.io with TLS already configured. Took about 30 seconds.

No Dockerfile. No build config. No YAML.

The app is private to your account by default.

What happened next was the interesting part

I didn't leave the conversation. I just kept going:

Create a Postgres database called myappdb and set up a parameter
store with the connection string as DATABASE_URL

That turned into three tool calls: create-database, setup-parameter-store, set-parameter. Database created, connection string wired into the app's config.

Then later when something broke:

Show me the last 50 error logs for my app

The agent called get-my-app-logs with level: error and tail: 50. I read the error right there in the chat, fixed the code, and:

Restart my app to pull the latest code

One call to restart-my-app. It pulled the latest commit and restarted the container.

The whole loop — code, deploy, break something, read logs, fix, redeploy — happened without switching windows. That's the part that felt genuinely different.

Other runtimes

Same flow works for Python and WebAssembly:

Deploy my FastAPI app from GitHub as a Python app called "apiserver"

Private repos work too — you pass a GitHub token and it gets stored as a Kubernetes secret.

If you don't have a repo hosted anywhere, there's a setup-git-repo tool that creates a hosted Git repo you can push to and then deploy from.

Custom domains

Map myapp.example.com to my app

One call to create-my-domain. TLS gets provisioned automatically.

On portability

One thing worth mentioning: everything running under the hood is open source. The web runner, the database (actual Postgres), the storage (MinIO-compatible). You can take the whole stack and move it elsewhere if you want to.

That matters more than usual here because the agent is making infrastructure decisions on your behalf inside a conversation. Knowing you can pull everything out and self-host it later is reassuring.

What people have built

Someone built Streaming Tech TV+ — a streaming platform with video transcoding, AI subtitles, analytics, and a CMS — in 36 hours using 6 AI agents across 13 services. That's 15,000 lines of code deployed to production by one person.

There are more examples at osaas.io/examples if you're curious.

Getting started

Sign up at osaas.io (there's a free tier)
Connect the MCP server to Claude Desktop, Cursor, Copilot, Windsurf, or whatever MCP client you use
Tell your agent to deploy something

The My Apps page is where you manage your deployed apps through the web UI, if you want that.

Built on Open Source Cloud. All components are open source. Revenue is shared with the projects that power the platform.

Adding user registration and authentication to your application with open web services

Jonas Birmé — Mon, 24 Feb 2025 00:47:17 +0000

In this blog post we will show how easy you can add user registration and authentication to your application using open web services in Eyevinn Open Source Cloud.

In this guide

Create a user database using an NoSQL open web service.
Launch an open web service for password authentication based on OpenAuth.
Develop a simple NextJS application as an example.

Prerequisites

An Eyevinn Open Source Cloud account. Sign up here for free.
Email service for sending email verification codes. In this example we will use the fake SMTP service.

Create the user database

Click on the instance card and open the web user interface for the database. In the user interface create a database that we can call users.

Note down the URL to the database instance, in our example it is https://eyevinnlab-blog.apache-couchdb.auto.prod.osaas.io.

Setup a fake SMTP mailer

For the purpose of you to be able to follow this example without having access to a real SMTP server for outgoing email you can create a fake SMTP mailer at Ethereal Email.

Create an account and note down the SMTP settings generated.

Launch password authentication service

Now navigate to the OpenAuth Password open web service and press "Create authservice".

Enter the following in the create dialog:

Name: blog
UserDbUrl: https://<db-user>:<db-password>@<db-url>/<db-name> where <db-url> is the hostname for the database instance you created and <db-name> the name of the database you created. In this example this is https://admin:secret@eyevinnlab-blog.apache-couchdb.auto.prod.osaas.io/users
SmtpMailerUrl: smtp://<smtp-user>:<smtp-password>@<smtp-host>:<smtp-port>. In our example with a fake SMTP mailer we have smtp://giovani.sporer@ethereal.email:NSjjETSjAYD7vKECF9@smtp.ethereal.email:587

Note down the URL to the password authentication service available on the instance card. In our example it is https://eyevinnlab-blog.eyevinn-openauth-pwd.auto.prod.osaas.io.

Develop a simple NextJS application

Now we will develop a simple NextJS application to verify that it works. It is based on the example application found in the OpenAuth GitHub repository.

Clone the OpenAuth repository.

% git clone git@github.com:openauthjs/openauth.git

Create a project folder for your application and copy the example code from the OpenAuth repository.

% mkdir my-app
% cd my-app
% cp -r ../openauth/examples/client/nextjs/* .

As we copied this example from a mono repo we need to uninstall the referenced openauth library and install the published package instead.

% npm uninstall @openauthjs/openauth 
% npm install --save @openauthjs/openauth

Install the other dependencies.

% npm install

Open the file app/auth.ts and replace the following in the file

export { subjects } from "../../../subjects"

with

import { createSubjects } from "@openauthjs/openauth/subject"
import { object, string } from 'valibot';

export const subjects = createSubjects({
  user: object({
    userId: string()
  })
});

Open the file app/page.tsx and change the following line:

  Logged in as <code>{subject.properties.id}</code>.

  Logged in as <code>{subject.properties.userId}</code>.

Then change the issuer URL http://localhost:3000 to the URL to the password authentication service you created, as in this example:

export const client = createClient({
  clientID: "nextjs",
  issuer: "https://eyevinnlab-blog.eyevinn-openauth-pwd.auto.prod.osaas.io",
})

Install the valibot dependency.

% npm install --save valibot

Now we can run the development server.

% npm run dev

Open your web browser and go to http://localhost:3000 and you will see the following.

Click on the Login with OpenAuth button.

Create a new account by clicking on the link Register.

Enter an email and password.

Go your inbox in the fake SMTP mailer (or a real one if you are using a real emailer).

Enter the code you received in the email.

A new user has now been created and we can verify that it is in our database.

And you are also logged in to the application.

Now we can press Logout and verify that we can login with the password we created.

And we are back in!

We can also verify that we can handle users that forgot their password. Press link Forgot password and enter the email.

Check the inbox for the code and enter it.

Conclusion

We have shown how simple you can implement user registration and password authentication in your application using open web services in Eyevinn Open Source Cloud. With open web services based on open source you are also not locked in with a single web service provider.

Creating a Ping service in Eyevinn Open Source Cloud

Jonas Birmé — Wed, 19 Feb 2025 21:28:57 +0000

The open web service Web Runner gives you the possibility to run your custom code in Eyevinn Open Source Cloud and building solutions based on a combination of the open web services available.

As an example we are going to build a simple "ping" service that provides an endpoint for checking whether a site is responding or not. It will save the checks to an SQL database.

Prerequisites

An account in Eyevinn Open Source Cloud. Sign up here
2 available services in your plan. If you have no remaining services in your plan you can purchase each service individually or upgrade your plan.
NodeJS installed

Install OSC Command Line Tool

We will start by installing the CLI for Eyevinn Open Source Cloud.

% npm install -g @osaas/cli@latest

Verify that it is correctly installed.

% osc -v
4.10.0

Now go to the Eyevinn Open Source Cloud web console and navigate to Settings/API and copy the Personal Access Token. Store this in the environment variable OSC_ACCESS_TOKEN.

% export OSC_ACCESS_TOKEN=<personal-access-token>

Initiate a NodeJS project

Create a project folder and initiate a NodeJS project.

% mkdir ping
% cd ping
% npm init

Install typescript.

% npm install --save-dev @types/node typescript
% npm install --save ts-node

We will be using fastify as the API middleware framework so let us install that.

% npm install --save fastify

Build the ping service

Create a folder for the source code and create an index.ts file in that folder.

Add the following code to the src/index.ts file.

import fastify from "fastify";

async function main() {
  const server = fastify();

  server.get('/', async (request, reply) => {
    reply.send('Hello World');
  });

  server.get<{
    Params: { site: string };
    Reply: {
      200: { up: boolean };
      '4xx': { error: string };
    }
  }>('/ping/:site', async (request, reply) => {
    const url = `https://${request.params.site}`;
    try {
      const response = await fetch(url, { method: 'GET' });
      const isUp = response.status >= 200 && response.status < 400;
      reply.code(200).send({ up: isUp });
    } catch (err) {
      reply.code(200).send({ up: false });
    }
  });

  server.listen({ host: '0.0.0.0', port: process.env.PORT ? Number(process.env.PORT) : 8080 }, (err, address) => {
    if (err) console.error(err);
    console.log(`Server listening at ${address}`);
  });
}

main();

Add the following line to the package.json

...
  "scripts": {
    "start": "ts-node src/index.ts",
    ...
  },
...

And add a file tsconfig.json with the following.

{
  "compilerOptions": {
    "target": "ESNext",
    "module": "commonjs",
    "rootDir": "./src",
    "outDir": "./dist",
    "esModuleInterop": true,
    "forceConsistentCasingInFileNames": true,
    "strict": true,
    "skipLibCheck": true
  }
}

Now let us test what we have created by running the start script.

% npm start
> ping@0.1.0 start
> ts-node src/index.ts

Server listening at http://127.0.0.1:8080

We can test the endpoint with the following curl command to check whether the site www.osaas.io is up.

% curl http://localhost:8080/ping/www.osaas.io
{"up":true}

Save checks to a database

It is often interesting to keep an uptime history so we want to save the result from all checks in a database.

We will be using a PostgreSQL database available as an open web service in Eyevinn Open Source Cloud. To be able to create the database from our application we will install the database module of the Eyevinn OSC javascript SDK and a Postgres client.

% npm install --save @osaas/client-db postgres

Now let us modify our src/index.ts and add that we will setup a database first and a table if it does not exist.

import { setupDatabase } from "@osaas/client-db";
import fastify from "fastify";
import postgres from "postgres";

async function main() {
  const server = fastify();
  const dbName = process.env.DB_NAME || 'sitemonitor';
  const dbUser = process.env.DB_USER || 'sitemonitor';
  const dbPassword = process.env.DB_PASSWORD || 'sitemonitor';

  const dbUrl = await setupDatabase('postgres', dbName, {
    username: dbUser,
    password: dbPassword,
    database: dbName,
  });  
  const sql = postgres(new URL(dbName, dbUrl).toString());
  await sql`CREATE TABLE IF NOT EXISTS checks (id BIGSERIAL PRIMARY KEY, site TEXT NOT NULL, up BOOLEAN NOT NULL, created_at TIMESTAMP NOT NULL DEFAULT NOW())`;

  server.get('/', async (request, reply) => {
    reply.send('Hello World');
  });

  server.get<{
    Params: { site: string };
    Reply: {
      200: { up: boolean };
      '4xx': { error: string };
    }
  }>('/ping/:site', async (request, reply) => {
    const url = `https://${request.params.site}`;
    try {
      const response = await fetch(url, { method: 'GET' });
      const isUp = response.status >= 200 && response.status < 400;
      await sql`INSERT INTO checks (site, up) VALUES (${url}, ${isUp})`;
      reply.code(200).send({ up: isUp });
    } catch (err) {
      await sql`INSERT INTO checks (site, up) VALUES (${url}, false)`;
      reply.code(200).send({ up: false });
    }
  });

  server.listen({ host: '0.0.0.0', port: process.env.PORT ? Number(process.env.PORT) : 8080 }, (err, address) => {
    if (err) console.error(err);
    console.log(`Server listening at ${address}`);
  });
}

main();

Now let us run it again.

% npm start

It will create a Postgres database called site monitor and we can verify this by going to the web console.

If you wanted to give the database another name or use another username or password we can provide that using environment variables, for example:

% DB_NAME=mynewdb npm start

Now when we do a ping it will also save the check and the result from it in the database.

sitemonitor=# select * from checks;                                                                               id |         site         | up |         created_at         
----+----------------------+----+----------------------------
  1 | https://www.osaas.io | t  | 2025-02-18 22:06:00.415521
  2 | https://www.osaas.io | t  | 2025-02-18 22:06:16.508421
  3 | https://www.osaas.io | t  | 2025-02-19 20:52:54.02972
(3 rows)

Run the code in Eyevinn Open Source Cloud

Now we want to make this ping service we created available online. For that we will use the open web service Web Runner. The Web Runner fetches the code from a private (or public) GitHub repository so we will first create a repository for the orchestrator we built.

Create a GitHub repository

% git init

Add a file called .gitignore that contains the following.

dist/
node_modules/

Create a GitHub repository in your GitHub account and push the code.

% git add
% git commit -m "my ping service"
% git remote add origin git@github.com:<your-git-org>/<git-repo>.git
% git branch -M main
% git push -u origin main

Create a GitHub personal access token

For access to you your GitHub repository you need to create a GitHub Personal Access Token first.

Verify your email address, if it hasn't been verified yet.
In the upper-right corner of any page on GitHub, click your profile photo, then click Settings.
In the left sidebar, click Developer settings.
In the left sidebar, under Personal access tokens, click Tokens (classic).
Select Generate new token, then click Generate new token (classic).
In the "Note" field, give your token a descriptive name.
To give your token an expiration, select Expiration, then choose a default option or click Custom to enter a date.
Select the scopes you'd like to grant this token. To use your token to access repositories from the command line, select repo. A token with no assigned scopes can only access public information. For more information, see Scopes for OAuth apps.
Click Generate token and copy it to the clipboard.

Create Web Runner instance

Now create a Web Runner instance with the link to the GitHub repository we created.

% osc create eyevinn-web-runner myping \
  -o GitHubUrl=https://github.com/<your-org>/<your-repo> \
  -o GitHubToken="<your-github-token>" \
  -o OscAccessToken="<your-osc-token>"
Instance created:
{
  name: 'myping',
  url: 'https://<yourtenant>-myping.eyevinn-web-runner.auto.prod.osaas.io',
  resources: {
    license: {
      url: 'https://api-eyevinn-web-runner.auto.prod.osaas.io/license'
    },
    app: {
      url: 'https://<yourtenant>-myping.eyevinn-web-runner.auto.prod.osaas.io/'
    }
  },
  GitHubUrl: 'https://github.com/<your-org>/<your-repo>',
  GitHubToken: '<your-github-token>',
  OscAccessToken: '<your-osc-token>',
  ConfigService: 'undefined'
}

After about a minute your ping service is available at the URL https://eyevinnlab-myping.eyevinn-web-runner.auto.prod.osaas.io and we can verify this with curl.

% curl https://eyevinnlab-myping.eyevinn-web-runner.auto.prod.osaas.io/ping/www.osaas.io
{"up":true}

And we can verify that it has saved it to the database.

sitemonitor=# select * from checks;
 id |         site         | up |         created_at         
----+----------------------+----+----------------------------
  1 | https://www.osaas.io | t  | 2025-02-18 22:06:00.415521
  2 | https://www.osaas.io | t  | 2025-02-18 22:06:16.508421
  3 | https://www.osaas.io | t  | 2025-02-19 20:52:54.02972
  4 | https://www.osaas.io | t  | 2025-02-19 21:08:51.192199
(4 rows)

Provide configuration environment variables to Web Runner

If you recall we made it possible to specify which database server it would create or use with the environment variable DB_NAME. How do we provide this configuration to the ping service running as a Web Runner?

For this we can use the Application Config open web service.

So let us start by creating an instance using the OSC command line tool.

% osc web config-create sitemonitor
Configuration service instance available at https://eyevinnlab-sitemonitor.eyevinn-app-config-svc.auto.prod.osaas.io

Opening this URL in a web browser you are presented with a user interface where you can manage configuration variables. Let us add a variable for the database name.

Now let us replace the web runner we created. Start by removing the one we created.

% osc remove eyevinn-web-runner myping
Are you sure you want to remove myping? (yes/no) yes
Instance removed

And when we now create it again we will refer to the application config service that we created.

% osc create eyevinn-web-runner myping \
  -o GitHubUrl=https://github.com/<your-org>/<your-repo> \
  -o GitHubToken="<your-github-token>" \
  -o OscAccessToken="<your-osc-token>" \
  -o ConfigService=sitemonitor

When we look at the logs we see that it has loaded the environment variables from the application config instance.

Now let us try to ping again.

% curl https://eyevinnlab-myping.eyevinn-web-runner.auto.prod.osaas.io/ping/www.osaas.io
{"up":true}

And check the new database mynewdb instead.

mynewdb=# select * from checks;
 id |         site         | up |         created_at         
----+----------------------+----+----------------------------
  1 | https://www.osaas.io | t  | 2025-02-19 21:20:43.954277
(1 row)

Conclusion

This was a start and example on how you with the Web Runner open web service can start building solutions based on available open web service in Eyevinn Open Source Cloud without having to provision or manage your own infrastructure.

Publish a NodeJS application online with Eyevinn Open Source Cloud

Jonas Birmé — Sat, 15 Feb 2025 12:09:59 +0000

The open web service Web Runner takes you from localhost to https in seconds. Deploy your Node application from your public or private GitHub repository and make it instantly available. This tutorial walks you through how to get started deploying your web application with Eyevinn Open Source Cloud.

In this guide

Get an API Access Token and setup project
Create a GitHub personal access token
Develop and publish a Hello World web application

Prerequisites

If you have not already done so, sign up for an OSC account. Sign up here for free.

Get an API Access Token and setup project

In the Eyevinn Open Source Cloud web console click on "Settings" in the navigation menu on the left. Then click on the tab "API" and copy the personal access token to the clipboard.

Store this token in your shell's environment in the environment variable OSC_ACCESS_TOKEN.

% export OSC_ACCESS_TOKEN=<access-token-copied-above>

We will create a web application using the NEXT.js framework in this example.

Create a new Next.js project by running this command.

% npx create-next-app@latest

After the prompts, create-next-app will create a folder with your project name and install the required dependencies. We can try it out by running it.

% npm run build
% npm start

Now you have your web application available on http://localhost:3000

Create a repository on GitHub

Login or signup on GitHub and create a repository for your web application and give it a name, for example web-hello-world. It can be a private or a public repository. Push the code in the project folder, for example.

% git remote add origin git@github.com:birme/web-hello-world.git
% git branch -M main
% git push -u origin main

Create a GitHub personal access token

For access to you your GitHub repository you need to create a GitHub Personal Access Token first.

Verify your email address, if it hasn't been verified yet.
In the upper-right corner of any page on GitHub, click your profile photo, then click Settings.
In the left sidebar, click Developer settings.
In the left sidebar, under Personal access tokens, click Tokens (classic).
Select Generate new token, then click Generate new token (classic).
In the "Note" field, give your token a descriptive name.
To give your token an expiration, select Expiration, then choose a default option or click Custom to enter a date.
Select the scopes you'd like to grant this token. To use your token to access repositories from the command line, select repo. A token with no assigned scopes can only access public information. For more information, see Scopes for OAuth apps.
Click Generate token and copy it to the clipboard.

Store token as a Service Secret

Now navigate to the Web Runner service in Eyevinn Open Source Cloud web console. Click on the tab "Service Secrets" and click on the button "New Secret". Give the secret a name and paste the GitHub token from your clipboard.

Create web runner

To make the web application available online you create a Web Runner instance.

Click on the tab “My web-runners” and then on the button “Create web-runner”. Enter the GitHub URL for your web application code and enter a reference to the secret you created. Enter the URL to the GitHub repository that you created.

Press create and you should now after a few minutes have an instance of your web application ready.

Give it a minute or two and then click on the instance card and it will open up a new window or tab to your web application. If you see an error the web application build process is still ongoing and you just might need to wait another minute or so.

You can now share the URL to this instance to stakeholders or users you want feedback from. In this example the URL is https://eyevinnlab-blog.eyevinn-web-runner.auto.prod.osaas.io

And as you see it is all running over HTTPS with a valid certificate.

To un-publish this web application you simply remove the instance that is running.

You can also use the OSC command line tool to create a web runner instance.

% npx @osaas/cli create eyevinn-web-runner blog \
  -o GitHubUrl="https://github.com/birme/web-hello-world" \
  -o GitHubToken="{{secrets.githubtoken}}"

GitHub Action

Using the GitHub action for OSC you can add this process to a build pipeline. For example automatically create a Web Runner instance of your application when a branch is updated for example.

Create a web runner instance of your web application in integration and end-to-end tests.

Conclusion

We have now given an example of how you quickly can share a prototype or a work-in-progress web application using an open web service in Eyevinn Open Source Cloud. As this is an open web service in Eyevinn Open Source Cloud you always have the option to run the same solution on your own premises as it is based on open source

If you want to try this out you can sign up and launch one instance all for free.

Working with Serverless Open Source Databases in Eyevinn Open Source Cloud

Jonas Birmé — Sat, 15 Feb 2025 10:17:42 +0000

Eyevinn Open Source Cloud reduces the barrier to open source while contributing to a sustainable model for open source by giving back a share of the revenue to the creator.

In this blog post we will walk through the different types of databases you have available at your fingertips without having to host the database servers yourself, and how easy it is to enable database support in your application.

In this guide

Get an API Access Token and setup project
Insert document in a NoSQL document database
Setup a messaging queue for your application
Setup a database for real-time data warehousing

Prerequisites

An Eyevinn Open Source Cloud account. Sign up here for free.

Get an API Access Token and setup project

In the Eyevinn Open Source Cloud web console click on "Settings" in the navigation menu on the left. Then click on the tab "API" and copy the personal access token to the clipboard.

Store this token in your shell's environment in the environment variable OSC_ACCESS_TOKEN.

% export OSC_ACCESS_TOKEN=<access-token-copied-above>

Setup a NodeJS project.

% mkdir db
% cd db
% npm init

Install the Javascript client SDK.

% npm install --save @osaas/client-core @osaas/client-db

Insert a document in a NoSQL database

As a first example we will setup and connect to a NoSQL database, and then insert a document.

Create a file called nosql.js and then add the following code to setup a CouchDB instance in Eyevinn Open Source Cloud with the name "nosql" if it does not already exists.

const { setupDatabase } = require("@osaas/client-db");
const nano = require('nano');

async function main() {
  const dbUrl = await setupDatabase("couchdb", "nosql", { rootPassword: 'secret' });
  const client = nano(dbUrl.toString());
  const dbList = await client.db.list();
  if (!dbList.includes('mydb')) {
    await client.db.create('mydb');
  }

  const db = client.use('mydb');
  await db.insert({
    title: 'Working with databases in Eyevinn OSC is a blast!'
  });  
}

main();

Once the database instance is created it will use the CouchDB javascript library to connect to the database, check whether a database called mydb exists and create if it does not exist already.

Then it will select this database and insert a JSON document. Before we can run this script we need to install the CouchDB javascript library.

% npm install --save nano

Then we can run the script.

% node nosql.js

Once completed we can verify this by navigating to the CouchDB service in Eyevinn Open Source Cloud web console and clicking on the instance card named nosql.

This was all you had to do to get started to store documents in a NoSQL database in your application, and the database is already deployed and available for production use.

Setup a messaging queue for your application

In the second example we will use Valkey in Eyevinn Open Source Cloud to setup a publish / subscribe messaging queue. Let us start with the subscriber part.

Create a file called subscriber.js and then add the following code to setup a Valkey instance and a client waiting for messages on a queue called messages.

const { setupDatabase } = require("@osaas/client-db");
const Redis = require('ioredis');

async function main() {
  const redisUrl = await setupDatabase("valkey", "messagequeue", {});
  console.log(redisUrl.toString());

  const client = new Redis(redisUrl.toString());
  await client.subscribe('messages');
  console.log('Waiting for messages...');
  client.on('message', (channel, message) => {
    console.log(`Received message: ${message} from ${channel}`);
  });
}

main();

Before we can run this script we need to install a Redis client library.

% npm install --save ioredis

Then we can run the subscriber.

% node subscriber.js
redis://default@172.232.131.169:10518
Waiting for messages...

Now we can move on writing an application that publish a message on this queue. Create a file called publisher.js and insert this code.

const { setupDatabase } = require("@osaas/client-db");
const Redis = require('ioredis');

async function main() {
  const redisUrl = await setupDatabase("valkey", "messagequeue", {});
  console.log(redisUrl.toString());
  const client = new Redis(redisUrl.toString());
  try {
    const receivedCount = await client.publish('messages', 'Working with Eyevinn OSC is a blast!');
    console.log(`Sent message to ${receivedCount} subscribers`);
  } catch (err) {
    console.error(err);
  } finally {
    await client.quit();
  }
}

main();

Then when we run this script we get.

% node publisher.js
redis://default@172.232.131.169:10518
Sent message to 1 subscribers

And on the subscriber application side we will get.

Waiting for messages...
Received message: Working with Eyevinn OSC is a blast! from messages

Setup a database for real-time data warehousing

In the final example we will setup a database that is suitable for working with large datasets. For this we will use ClickHouse that is available as an open web service.

Create a file called warehouse.js and insert the following code.

const { setupDatabase } = require("@osaas/client-db");
const { createClient } = require('@clickhouse/client');

async function main() {
  const dbUrl = await setupDatabase('clickhouse', 'warehouse', { password: 'secret' });
  console.log(dbUrl.toString());
  const client = createClient({
    url: dbUrl.toString()
  });
  await client.command({
    query: `
  CREATE OR REPLACE TABLE trips
  (
    trip_id UInt32,
    vendor_id Enum8('1' = 1, '2' = 2, '3' = 3, '4' = 4, 'CMT' = 5, 'VTS' = 6, 'DDS' = 7, 'B02512' = 10, 'B02598' = 11, 'B02617' = 12, 'B02682' = 13, 'B02764' = 14, '' = 15),
    pickup_date Date,
    pickup_datetime DateTime,
    dropoff_date Date,
    dropoff_datetime DateTime,
    store_and_fwd_flag UInt8,
    rate_code_id UInt8,
    pickup_longitude Float64,
    pickup_latitude Float64,
    dropoff_longitude Float64,
    dropoff_latitude Float64,
    passenger_count UInt8,
    trip_distance Float64,
    fare_amount Float32,
    extra Float32,
    mta_tax Float32,
    tip_amount Float32,
    tolls_amount Float32,
    ehail_fee Float32,
    improvement_surcharge Float32,
    total_amount Float32,
    payment_type Enum8('UNK' = 0, 'CSH' = 1, 'CRE' = 2, 'NOC' = 3, 'DIS' = 4),
    trip_type UInt8,
    pickup FixedString(25),
    dropoff FixedString(25),
    cab_type Enum8('yellow' = 1, 'green' = 2, 'uber' = 3),
    pickup_nyct2010_gid Int8,
    pickup_ctlabel Float32,
    pickup_borocode Int8,
    pickup_ct2010 String,
    pickup_boroct2010 String,
    pickup_cdeligibil String,
    pickup_ntacode FixedString(4),
    pickup_ntaname String,
    pickup_puma UInt16,
    dropoff_nyct2010_gid UInt8,
    dropoff_ctlabel Float32,
    dropoff_borocode UInt8,
    dropoff_ct2010 String,
    dropoff_boroct2010 String,
    dropoff_cdeligibil String,
    dropoff_ntacode FixedString(4),
    dropoff_ntaname String,
    dropoff_puma UInt16
)
ENGINE = MergeTree
PARTITION BY toYYYYMM(pickup_date)
ORDER BY pickup_datetime;
    `
  });
  await client.command({
    query: `
INSERT INTO trips
SELECT * FROM s3(
    'https://datasets-documentation.s3.eu-west-3.amazonaws.com/nyc-taxi/trips_{1..2}.gz',
    'TabSeparatedWithNames', "
    trip_id UInt32,
    vendor_id Enum8('1' = 1, '2' = 2, '3' = 3, '4' = 4, 'CMT' = 5, 'VTS' = 6, 'DDS' = 7, 'B02512' = 10, 'B02598' = 11, 'B02617' = 12, 'B02682' = 13, 'B02764' = 14, '' = 15),
    pickup_date Date,
    pickup_datetime DateTime,
    dropoff_date Date,
    dropoff_datetime DateTime,
    store_and_fwd_flag UInt8,
    rate_code_id UInt8,
    pickup_longitude Float64,
    pickup_latitude Float64,
    dropoff_longitude Float64,
    dropoff_latitude Float64,
    passenger_count UInt8,
    trip_distance Float64,
    fare_amount Float32,
    extra Float32,
    mta_tax Float32,
    tip_amount Float32,
    tolls_amount Float32,
    ehail_fee Float32,
    improvement_surcharge Float32,
    total_amount Float32,
    payment_type Enum8('UNK' = 0, 'CSH' = 1, 'CRE' = 2, 'NOC' = 3, 'DIS' = 4),
    trip_type UInt8,
    pickup FixedString(25),
    dropoff FixedString(25),
    cab_type Enum8('yellow' = 1, 'green' = 2, 'uber' = 3),
    pickup_nyct2010_gid Int8,
    pickup_ctlabel Float32,
    pickup_borocode Int8,
    pickup_ct2010 String,
    pickup_boroct2010 String,
    pickup_cdeligibil String,
    pickup_ntacode FixedString(4),
    pickup_ntaname String,
    pickup_puma UInt16,
    dropoff_nyct2010_gid UInt8,
    dropoff_ctlabel Float32,
    dropoff_borocode UInt8,
    dropoff_ct2010 String,
    dropoff_boroct2010 String,
    dropoff_cdeligibil String,
    dropoff_ntacode FixedString(4),
    dropoff_ntaname String,
    dropoff_puma UInt16
") SETTINGS input_format_try_infer_datetimes = 0    
`
  });
}

main();

When we run this script we will create a ClickHouse database, a table for Taxi trips and insert some sample data in that table.

Install the ClickHouse javascript client.

% npm install --save @clickhouse/client

Then run our script.

% node warehouse.js
https://default:secret@eyevinnlab-warehouse.clickhouse-clickhouse.auto.prod.osaas.io/

We can now verify that we have inserted records in the table by going to the database web user interface available at https://eyevinnlab-warehouse.clickhouse-clickhouse.auto.prod.osaas.io/play or by clicking on the database instance card in the Eyevinn Open Source Cloud web console.

Let us count how many trips we have in the table.

We could then compute the average cost based on the number of passengers.

Conclusion

Now we have given you some examples of how quickly you can enabling database support in your application without having to worry about the deployment and infrastructure for it. Available as open web services in Eyevinn Open Source Cloud you are not locked in with a specific cloud vendor as it is based on open source.

NoSQL Key-Value database with open web services

Jonas Birmé — Mon, 10 Feb 2025 20:31:06 +0000

In this blog post we will show how quickly you can get started with storing data in a NoSQL Key-Value database in the cloud based on open web services in Eyevinn Open Source Cloud. Based on Apache CouchDB as a service in Eyevinn Open Source Cloud you don't have to manage and maintain the database server yourself and can immediately start to store and read your data.

In this guide

Get an API Access Token and setup project
Setup and create a database
Insert and read documents

Prerequisites

An Eyevinn Open Source Cloud account.

Get an API Access Token and setup project

Navigate to Settings / API in the Eyevinn Open Source Cloud web console.

Copy this token and store in your shell's environment in the environment variable OSC_ACCESS_TOKEN.

% export OSC_ACCESS_TOKEN=<access-token-copied-above>

Setup a NodeJS project.

% mkdir nosql
% cd nosql
% npm init

Install the Javascript client SDK.

% npm install --save @osaas/client-core @osaas/client-services

A NoSQL database for a blogging platform

As an example we will build a simple blog platform where we will store the blog posts in a NoSQL database. Instead of using tables, a NoSQL database stores data in JSON-like documents.

Create a file called blog.js and then add the following code that will create an CouchDB instance in Eyevinn Open Source Cloud with the name "example" if it does not already exists. Then it will create a database called "blog".

const { Context } = require('@osaas/client-core');
const {
  createApacheCouchdbInstance,
  getApacheCouchdbInstance
} = require('@osaas/client-services');
const nano = require('nano');

async function setup() {
  const ctx = new Context();
  let instance = await getApacheCouchdbInstance(ctx, 'example');
  if (!instance) {
    instance = await createApacheCouchdbInstance(ctx, {
      name: 'example',
      AdminPassword: 'secret'
    });
  }
  const url = new URL(instance.url);
  url.password = instance.AdminPassword;
  url.username = 'admin';
  const client = nano(url.toString());
  const dbList = await client.db.list();
  if (!dbList.includes('blog')) {
    await client.db.create('blog');
  }
  return client.db.use('blog');
}

We will use the Apache CouchDB client SDK for javascript called nano so we need to install that dependency.

% npm install --save nano

Now add a main() function to our file.

async function main() {
  const db = await setup();
}

Then we can try to run this file.

% node blog.js

To verify that a database has been created we can go to the Eyevinn Open Source Cloud web console and click on the instance card for the database instance called "example".

After logging in with the credentials that we specified when creating the instance we find the list of databases on this instance.

We now see that we have a database called "blog" that we created from our application.

Insert and read documents

Now let us add a document in the database by adding the following to our main function.

async function main() {
  const db = await setup();
  await db.insert({
    title: 'Getting started with NoSQL in Eyevinn OSC',
    content: 'Learn the basics of NoSQL in Eyevinn OSC',
    author: 'Jonas Birmé',
    createdAt: new Date()
  });
}

Running the application again we can check in the web console that a new document has been inserted.

To query data from this database we can replace the insert in our main function with the following:

async function main() {
  const db = await setup();
  const posts = await db.list({ include_docs: true });
  posts.rows.forEach((post) => console.log(post.doc));
}

Now running this application we will get.

% node blog.js
{
  _id: '448ac3db332c49841771e2068900197b',
  _rev: '1-dabd2ae20ac9fa41dfbee4d87dcc7861',
  title: 'Getting started with NoSQL in Eyevinn OSC',
  content: 'Learn the basics of NoSQL in Eyevinn OSC',
  author: 'Jonas Birmé',
  createdAt: '2025-02-10T20:14:53.582Z'
}

We can also query all blog posts written by the author "Jonas Birmé".

async function main() {
  const db = await setup();
  const result = await db.find({
    selector: {
      author: { "$eq": "Jonas Birmé" }
    },
    fields: [ "title" ]
  });
  result.docs.forEach((post) => console.log(post));
}

And the output will then be:

% node blog.js
{ title: 'Getting started with NoSQL in Eyevinn OSC' }

Conclusion

This was a guiding example of how you quickly can get a NoSQL database available for your application without having to worry about database servers and hosting infrastructure. Something made possible with Apache CouchDB available as an open web service in Eyevinn Open Source Cloud. You are also not locked in with a specific cloud vendor as it is based on open source.

Publish-subscribe messaging with open web services

Jonas Birmé — Mon, 10 Feb 2025 13:27:41 +0000

In this blog post we will show an example of pub/sub messaging using open web services available in Eyevinn Open Source Cloud. Publish-subscribe messaging, or pub/sub messaging, is an asynchronous communication model that is central for a scalable and distributed system of modules or services.

Based on the open web service Valkey in Eyevinn Open Source Cloud we can build an application using the pub/sub messaging model.

In this guide

Get an API Access Token and setup project
Develop a subscriber example application
Develop a publisher example application

Prerequisites

An Eyevinn Open Source Cloud account.

Get an API Access Token and setup project

Navigate to Settings / API in the Eyevinn Open Source Cloud web console.

Copy this token and store in your shell's environment in the environment variable OSC_ACCESS_TOKEN.

% export OSC_ACCESS_TOKEN=<access-token-copied-above>

Setup a NodeJS project.

% mkdir pubsub
% cd pubsub
% npm init

Install the Javascript client SDK.

% npm install --save @osaas/client-core @osaas/client-services

Subscriber application

We will start by developing the subscriber application that will register (subscribe) to topics of interest.

Create a file called subscriber.js. Then add the following code to setup the Valkey instance that will be managing all topics and messages. Valkey is an open source, in-memory data store that is API compatible with a Redis client.

const { Context, getPortsForInstance } = require('@osaas/client-core');
const {
  createValkeyIoValkeyInstance,
  getValkeyIoValkeyInstance
} = require('@osaas/client-services');

async function setup() {
  const ctx = new Context();
  let valkey = await getValkeyIoValkeyInstance(ctx, 'example');
  if (!valkey) {
    valkey = await createValkeyIoValkeyInstance(ctx, {
      name: 'example',
      Password: 'secret'
    });
  }
  const token = await ctx.getServiceAccessToken('valkey-io-valkey');
  const ports = await getPortsForInstance(
    ctx,
    'valkey-io-valkey',
    'example',
    token
  );
  const port = ports.find((p) => p.internalPort === 6379);
  if (port) {
    return `redis://:${valkey.Password}@${port.externalIp}:${port.externalPort}`;
  }
  throw new Error('No redis port found');
}

The setup function will return a Redis URL to the Valkey instance.

Next step is to start waiting for messages and first we need to install a Redis client.

% npm install --save ioredis

We will add the following to the subscriber.js file to subscribe on a topic called "messages".

const Redis = require('ioredis');

async function main() {
  const redisUrl = await setup();
  const client = new Redis(redisUrl);
  try {
    await client.subscribe('messages');
    console.log('Waiting for messages...');
    client.on('message', (channel, message) => {
      console.log(`Received message: ${message} from ${channel}`);
    });
  } catch (err) {
    console.error('Error:', err);
  }
}

main();

Now running this application we will get.

% node subscriber.js
Waiting for messages...

Publisher application

Now open a new terminal and create a file called publisher.js. Copy the setup function we created in the subscriber application and in addition add the following to this file.

async function publishMessage(topic, message) {
  const redisUrl = await setup();
  const redisClient = new Redis(redisUrl);
  try {
    const receivedCount = await redisClient.publish(topic, message);
    console.log(
      `Message "${message}" published to channel "${topic}". Received by ${receivedCount} subscribers.`
    );
  } catch (err) {
    console.error('Error publishing message', err);
  } finally {
    await redisClient.quit();
  }
}

if (!process.argv[2]) {
  console.error('Please a message to publish');
  process.exit(1);
}
publishMessage('messages', process.argv[2]);

Now run the publisher application and publish a Hello world message.

% node publisher.js "Hello world"
Message "Hello world" published to channel "messages". Received by 1 subscribers.

And we will see that the subscriber application will output the message.

Waiting for messages...
Received message: Hello world from messages

Conclusion

You have now successfully created a pub/sub messaging application using the open source Valkey in-memory data store for the messaging. With Valkey as an open web service in Eyevinn Open Source Cloud you could immediately start building your pub/sub messaging application without having to host the Valkey instance yourself. You also avoided to be locked in with a specific cloud vendor as it is based on open source.

Creating a web video application

Jonas Birmé — Wed, 05 Feb 2025 20:12:57 +0000

As a continuation to the blog post Stream Video with Open Web Services we will in this post develop a web application for streaming the video we have created.

In this guide we will use the build tool Vite to setup a web project for a web application based on the React framework.

Setup the React Typescript project

Run the following command to scaffold a new project based on React template.

% npm create vite@latest my-video-app -- --template react-ts

Then run:

% cd my-video-app
% npm install
% npm run dev

Open your browser to http://localhost:5173/ and you will see the following template.

Create a Video Player component

Now it is time to add a video player component. We will use the open source web player from Eyevinn in this example.

First install the library.

% npm install --save @eyevinn/web-player

Then we will create a folder for our components

% mkdir src/components

In this folder we will create a file called Player.tsx containing the following code.

import webplayer from '@eyevinn/web-player';
import { useEffect, useRef } from 'react';

import '@eyevinn/web-player/dist/webplayer.css';

export default function Player({
  src,
  autoplay = false
}: {
  src: string;
  autoplay?: boolean;
}) {
  const elRef = useRef<HTMLDivElement>(null);
  useEffect(() => {
    if (elRef.current) {
      const instance = webplayer(elRef.current, {});
      instance.player.load(src, autoplay);
      return () => {
        instance.destroy();
      };
    }
  }, [src]);

  return <div ref={elRef} className="h-full" />;
}

Use the Player component

Now we can use this Player component on our main page. Replace the contents in the file src/App.tsx and replace the src property with the URL to the video you created in the previous blog.

import { useState } from 'react'
import './App.css'
import Player from './components/Player'

function App() {
  const [count, setCount] = useState(0)

  return (
    <>
      <h1>Vite + React + Eyevinn OSC</h1>
      <div className="card">
        <Player src="https://eyevinnlab-devguide.minio-minio.auto.prod.osaas.io/devguide/VINN/52e124b8-ebe8-4dfe-9b59-8d33abb359ca/index.m3u8"/>
        <button onClick={() => setCount((count) => count + 1)}>
          count is {count}
        </button>
      </div>
    </>
  )
}

export default App

Now when updating the browser you should see the video player with your video.

Make the web application available online

Now you have a working application running locally on your computer and it is time to make it available online. To make it available online we will be using Eyevinn Open Source Cloud to host this website as described in a blog post on Eyevinn Open Source Cloud blog.

First modify the vite config file vite.config.ts to use a relative base url (default expects the root /).

import { defineConfig } from 'vite'
import react from '@vitejs/plugin-react'

// https://vite.dev/config/
export default defineConfig({
  base: './',
  plugins: [react()],
})

Then we can build the application by running the following command.

% npm run build

Go to the web console of Eyevinn Open Source Cloud and obtain the access token available under Settings. Copy the token and store it in the environment variable OSC_ACCESS_TOKEN.

% export OSC_ACCESS_TOKEN=YOUR_TOKEN

Now run the following command to deploy the build. We name the website “video” which will be the bucket where the files are placed.

% npx @osaas/cli@latest web publish -s video dist/

Now your web application is available online at the address returned by the command above. In our example it is available at https://eyevinnlab-video.minio-minio.auto.prod.osaas.io/video/index.html

Conclusion

This gives you an example of how you can build a video streaming application based on open source without having to host everything in-house. From video processing to the deployment of the web application based on open web services in Eyevinn Open Source Cloud.

As everything is based on open source you always have the option to bring it in-house if you want to.