Deploy a Stateless Python Micro-App to Deta Space with Deta Base

The problem: disk writes disappear after a restart

You write a small Python micro-app, push it to Deta Space, and watch it work at a public URL. Then the sandbox restarts or you redeploy, and a counter saved to a local file is back at zero. Deta Space runs user-authored micro-apps in isolated sandboxes. Treat any file written to the app's local filesystem as temporary storage that can vanish when the container is recycled.

Use stateless compute and Deta Base for state

A sound engineering choice is to separate compute from state. Keep the micro-app stateless: all code and configuration live in the deployment bundle, while durable data such as counters, preferences, or records lives in Deta Base, a key-value document store attached to your space. Because the base exists outside the app sandbox, a value written before a restart should still be readable afterward.

Worked example: a visit counter

The following snippet shows the pattern, not a tested integration. Verify the exact SDK import and method names in the current Deta documentation before copying it.

# Placeholder API: confirm exact names in official docs
from deta_base import Base

counter = Base("app-counter")

def handle_request(request):
    current = counter.get("visits") or 0
    counter.put("visits", current + 1)
    return {"visits": current + 1}

• Base("app-counter") opens or creates a logical store named app-counter.
• get reads the current value; put writes it back.
• No data is written to /tmp, the working directory, or any local path.

Deploy and verify

Run these steps in a local terminal where you have the Deta Space CLI installed and authenticated to your space. Replace placeholders in angle brackets with your own values.

1. Create a minimal app folder containing the Python handler and any required manifest.
2. Initialize the space app: <space-cli> init <APP_NAME>. Confirm the exact command name in current documentation.
3. Push or deploy the app: <space-cli> push or <space-cli> deploy, depending on your CLI version.
4. Open the assigned public URL. Expect an HTTP 200 response and the counter to increment on each request.
5. Redeploy or restart the app through the space interface.
6. Request the URL again. The counter should continue from the previous value, proving state survived in Deta Base.

Risks: an incorrect SDK call may write to the wrong base or fail silently. A public URL may expose the app without authentication, so review access controls before storing sensitive data.

Trade-offs and limitations

Factor	Local sandbox disk	Deta Base
Durability	Lost on restart or redeploy	Persists across restarts
Best fit	Temporary caches, uploads	Counters, preferences, records
Scale	Limited to one instance	Suited for small durable state

• Deta Base is appropriate for small state, not large files or complex relational queries.
• The exact CLI names, API endpoints, pricing, and current support status of Deta Space are unverified as of this writing. Check official documentation before relying on this pattern for production workloads.
• Public exposure and authentication models differ by deployment; do not assume the app is private.

Rollback and closing checklist

Deploying changes the state of your space. To roll back, redeploy the previous known-good app bundle or disable the app from your space dashboard, then confirm the public URL returns the earlier behavior.

Before considering the migration complete:

• Confirm the app responds at its public URL after a fresh deploy.
• Write a value to Deta Base, redeploy the app, and read the value again.
• Review who can access the public URL and whether authentication is required.
• Verify the CLI and SDK commands against current documentation.