Deploy a Deno Microapp to Detaspace with Built-in Key-Value Storage

You need a small private app without operating a database

You need a link shortener, reading-list tracker, or webhook receiver, but you do not want to rent a VPS, manage certificates, or run a database just to persist a few rows. Detaspace is Deta's personal cloud OS: it runs microapps in your own isolated space, provisions a subdomain, and handles TLS. The space CLI deploys Deno applications, and each app can read and write built-in key-value storage without provisioning an external database.

This post walks through deploying a minimal Deno microapp to Detaspace, checking that key-value reads and writes work, and understanding where the platform's limits are not yet well documented. Treat the commands below as a template to verify against Deta's current documentation, because Detaspace's CLI behavior and maintenance status may have changed since this material was written.

Start with a Deno fetch handler

Detaspace microapps are typically Deno applications that expose HTTP handlers. A minimal app listens for fetch events and returns a response. Create a directory, then a file named main.ts:

addEventListener('fetch', (event) => {
  event.respondWith(handleRequest(event.request));
});

async function handleRequest(request: Request): Promise {
  const url = new URL(request.url);

  if (url.pathname === '/kv' && request.method === 'POST') {
    return new Response('storage endpoint not wired yet', { status: 501 });
  }

  return new Response('Hello from Detaspace', { status: 200 });
}

Run commands locally on your workstation with normal user permissions. You do not need root or sudo to install or use the space CLI. Replace <APP_DIR> with the folder containing your app and <SPACE_NAME> with your Detaspace subdomain or space identifier.

Deploy with the space CLI

1. Install the space CLI from Deta's official site. Confirm the toolchain:

space --version

Expected check: a version string prints without error. If the command is not found, the CLI is not on your PATH.

1. Initialize and deploy:

cd <APP_DIR>
space init
space deploy

Permissions: normal user. The CLI reads files in the current directory and uploads them to your Detaspace space. Risk: space deploy changes state and can overwrite an existing deployment under the same space name. Keep a copy of the previous working code before redeploying.

1. Verify routing and TLS:

curl -i https://<SPACE_NAME>.detaspace.app

Expected check: HTTP 200 and a TLS-secured response. If you see a certificate warning or DNS failure, the deployment may still be propagating or the subdomain may be incorrect.

Rollback: Because deploy changes state, the practical rollback is to redeploy the last known good version of your code. Inspect space logs after a failed deploy to identify the error before redeploying. I cannot confirm a dedicated one-command rollback from current documentation.

Use built-in key-value storage and identity

Detaspace provides app-accessible key-value storage, and the gateway sets headers identifying the current space user. The exact storage API and header names should be confirmed in current Deta docs. Conceptually, your handler might read an identity header and use a storage binding to get and put values.

Do not hardcode secrets in main.ts. Use environment variables or the CLI's secret management if available, and verify how Detaspace exposes them before storing credentials.

Diagnostic decision: If /kv returns errors, check space logs first. Distinguish between application errors (your Deno code threw) and platform errors (storage unavailable, quota exceeded, or authentication header missing):

space logs

Expected check: recent log lines show request paths and status codes. Absence of logs may mean the request never reached the app.

Trade-offs and what to verify before relying on it

• Quotas: CPU, memory, storage, and outbound request limits are not well documented. Test limits before production workloads.
• Backups and SLA: Uptime SLAs, backup schedules, and support channels are unclear. Do not treat Detaspace as a replacement for managed infrastructure.
• Related services: Deta Base and Deta Drive are separate Deta cloud products; confirm whether they are included in Detaspace or require external accounts.
• Maintenance status: Verify current CLI commands and API availability on Deta's official site and community channels before building on Detaspace in 2026.

Practical way to check the result: After deployment, write a value through your app's storage endpoint, then read it back in a separate request while logged into Detaspace. If the read returns the written value, key-value persistence is working for your user context.

Closing

Detaspace can remove the operational overhead of a small personal app, but it is not yet a fully documented managed platform. Deploy a throwaway microapp first, confirm TLS, storage, and logs behave as expected, and keep backups of any data you store there.