# Oikina by Mohtasham Murshid Madani [Canonical page](https://www.mohtasham.dev/work/oikina) A small cloud for deploying apps built by people and coding agents. Oikina works from a project folder and gives coding agents one opinionated path from a local app to a running URL. The hosted beta supports static and constrained full-stack apps, persistent SQLite, declared server actions, encrypted server secrets, immutable releases, and rollback. Role: Founder. Updated 2026-08-26. 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 design - CLI - Runtime and infrastructure ## Current beta - Built independently - 5+ testers - Under 10-second deploys ## Working today - Full-stack apps - Persistent SQLite - Releases 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. ## 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. ## 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. ## From an idea to a running app 1. Describe the app: A person asks a coding agent to build a small tool. 2. Build locally: The agent writes the interface, actions, and data model. 3. Validate: The CLI checks the manifest, build, routes, and migrations. 4. Deploy: Oikina uploads and publishes an immutable release. 5. Share the URL: The running app receives its Oikina subdomain. ## Current hosted architecture Build: Person + coding agent: Create the app in a local project folder Prepare: Oikina CLI: Build, validate, bundle, and upload Publish: Hosted Runtime: Authenticate and install the release; Release registry: Keep immutable versions and the active pointer Run: Static gateway: Serve the active public files; Isolated action worker: Run one declared server action; Persistent SQLite: Keep app data across releases and workers ## project folder to hosted result - oikina.json: Validated app contract. Identity, build output, action routes, and migrations - dist/: Immutable public artifact. Bounded regular files with unsafe paths and symlinks rejected - server/actions.ts: Private server bundle. Stored separately and run only for declared routes - migrations: Persistent app SQLite. Ordered changes bound to one stable app identity - .env.production: Public and private values split. Server values are encrypted and injected into workers - deployment: Release history and rollback. A verified active pointer selects the version being served ## Deployment flow ```text $ npx oikina new incident-tracker $ cd incident-tracker $ npx oikina dev $ npx oikina validate $ npx oikina login $ npx oikina deploy ``` npx oikina deploy Develop locally, validate the project, and deploy it through the same CLI. I built Oikina so the agent can finish the job instead of handing me a list of dashboards to configure. - [Visit Oikina ↗](https://oikina.com) [Visit Oikina](https://oikina.com)