Oikina

Oikina is my startup. I started it because coding agents could build most of a small app, but they could not finish deploying it. I still had to open several dashboards, create a database, configure authentication, set up storage, and move credentials between services. A quick one-off app kept turning into an infrastructure job.

I wanted one opinionated place where an agent could deploy the app for me. Oikina works from a project folder. Its CLI builds the app, checks its configuration, uploads it, and publishes it to an Oikina subdomain. In my current beta tests, a normal deployment finishes in under ten seconds.

My work

Product designCLIRuntime and infrastructure

Current beta

Built independently5+ testersUnder 10-second deploys

Working today

Full-stack appsPersistent SQLiteReleases and rollback

Why I call it a small cloud

Small apps should not require a collection of accounts and credentials before anyone can use them. Most of the apps I build are tools for a handful of people. They need somewhere to run, a database, a little server code, and a safe way to update them. They do not need an open-ended cloud setup.

Oikina is deliberately narrow. It is not another tool that generates the app. The coding agent remains the place where the app is created. Oikina gives that agent a predictable way to develop, validate, and deploy it. The current beta does not replace every dashboard yet, but it proves that deployment can become one short command instead of a manual setup session.

The Oikina landing page introducing the small cloud — The public Oikina site introduces the small-cloud idea and its opinionated deployment model.

From an idea to a running app

01Describe the app

A person asks a coding agent to build a small tool.

02Build locally

The agent writes the interface, actions, and data model.

03Validate

The CLI checks the manifest, build, routes, and migrations.

04Deploy

Oikina uploads and publishes an immutable release.

05Share the URL

The running app receives its Oikina subdomain.

The agent stays in the development loop and uses Oikina as the deploy target.

What works in the beta

Oikina currently deploys static sites and constrained full-stack React apps. A full-stack app can include declared server actions, migrations, persistent SQLite data, reactive queries, and encrypted server secrets. Every release is kept as an immutable version, and an earlier release can be restored through rollback.

Server actions run inside fresh, networkless workers. The worker can disappear after the request without taking the app's data with it. SQLite belongs to the app rather than the release, so its data survives new deployments, rollbacks, and worker restarts. Five-plus friends and colleagues are testing the beta. App-user authentication, file storage, background jobs, arbitrary backend servers, and customer-hosted runtimes are not available yet.

Current hosted architecture

Build

Person + coding agentCreate the app in a local project folder

Prepare

Oikina CLIBuild, validate, bundle, and upload

Publish

Hosted RuntimeAuthenticate and install the release

Release registryKeep immutable versions and the active pointer

Run

Static gatewayServe the active public files

Isolated action workerRun one declared server action

Persistent SQLiteKeep app data across releases and workers

Public files and server actions resolve from the same active release. App data lives separately so deployment and rollback do not replace it.

project folderhosted result

oikina.json

Validated app contractIdentity, build output, action routes, and migrations

dist/

Immutable public artifactBounded regular files with unsafe paths and symlinks rejected

server/actions.ts

Private server bundleStored separately and run only for declared routes

migrations

Persistent app SQLiteOrdered changes bound to one stable app identity

.env.production

Public and private values splitServer values are encrypted and injected into workers

deployment

Release history and rollbackA verified active pointer selects the version being served

The project folder becomes a release, while the app's data remains independent from that release.

Deployment flowterminal

$ npx oikina new incident-tracker
$ cd incident-tracker
$ npx oikina dev
$ npx oikina validate
$ npx oikina login <deploy-token>
$ npx oikina deploy

npx oikina deploy

Develop locally, validate the project, and deploy it through the same CLI.

The part I had to learn

I had deployed plenty of apps before Oikina. I had never built the system doing the deployment. This was my first time going this deeply into packaging applications, checking uploads, isolating private server code, preserving data, switching releases, and operating the infrastructure underneath it.

There was no single difficult piece. The whole path had to work together. An upload could not escape its project folder. Private server code could not become a public file. A failed release could not replace the working one. SQLite had to survive while workers and releases came and went. Rollback had to restore verified code without rolling back the user's data. Getting all of that working was the hardest part of the project, and the reason I learned so much from building it.