Cloud Overview
Nativeblocks Cloud is the hosted backend that stores and delivers your deployed frames to mobile users in real time.
Nativeblocks Cloud is the backend infrastructure that powers the code-push platform. It sits between your CLI and your users' devices, handling everything from frame storage to release management.
What the Cloud does
| Capability | Details |
|---|---|
| Frame hosting | When you run frame deploy command, the compiled frame is uploaded to the cloud. The SDK fetches the latest active frame on each app open, with no App Store or Play Store review needed. |
| Release management | The cloud tracks versioned frame tags, supports targeted rollouts (by user, app version, or percentage), and lets you roll back to any previous tag instantly. |
| Studio backend | The web studio for monitoring tag distribution, daily active users, and triggering rollbacks is backed by the cloud. |
| Component registry | When you annotate components with @NativeBlock / @NativeAction and sync them, they are registered with the Nativeblocks servers so the CLI can generate typed DSL wrappers. |
How it works
- You write a frame in Kotlin, TypeScript, or Swift and run
frame deploycommand. - The compiled frame is uploaded to the cloud and linked to the tag.
- The Studio lets you promote the tag to production (or roll it out gradually).
- On the next app open the SDK fetches the active frame and renders it without any new release.
Deployment options
| Option | Description |
|---|---|
| Nativeblocks Cloud | Fully managed. Sign up at nativeblocks.io and start deploying immediately. |
| Core API Self-Hosted | Run nativeblocks-core-api on your own infrastructure with Docker. Requires a license key. See Core API Self-Hosting. |
| Studio Self-Hosted | Run nativeblocks-studio on your own infrastructure with Docker. Connects to a self-hosted or cloud Core API. See Studio Self-Hosting. |
Reference architecture
This is how a Nativeblocks stack plugs into a typical product. Your platform never renders Nativeblocks UI; it only hands the client SDK its apiKey and apiUrl. Whether you run Core API and Studio yourself or use Nativeblocks Cloud, the call paths are the same.
Runtime: serving UI to the app
On app start, your app's config (or init) API returns apiKey and apiUrl (the SDK gateway URL) to the client SDK. The SDK then calls Core API's /gateway/init directly with those credentials and renders the returned frames natively.
The stack & operations
Nginx terminates TLS in front of Core API (:8080) and Studio (:80). Core API uses PostgreSQL (migrations auto-run at startup), Valkey/Redis (cache + event queue), and an S3-compatible bucket (assets). It validates its license against admin.api.nativeblocks.io at startup and periodically, pushes hot-reload events to the realtime service, and exposes /metrics for Prometheus to scrape. Logs go to stdout and to whatever log manager you prefer (Sentry, Filebeat, or anything else).