EmuView Documentation
Guides, API references, and everything you need to build with EmuView.
Browse by section
Getting Started
6 pages
Collections
11 pages
Permissions
7 pages
Authentication
5 pages
Files
1 page
Flocks
3 pages
Automation
7 pages
SDK
21 pages
Studio
6 pages
Blueprints
7 pages
API Reference
12 pages
Maps
4 pages
Performance
8 pages
Administration
16 pages
Self-Hosting
4 pages
Troubleshooting
5 pages
Changelog
1 page
A backend in minutes, not weeks
EmuView is an API-first Backend-as-a-Service that runs entirely on Cloudflare's edge network. You define your data collections, set permissions, and get a fully documented REST API — no server code, no infrastructure to manage, no cold starts. Your frontend can be Svelte, React, Vue, or plain HTML; it talks to EmuView over standard HTTPS.
How it works
You create collections (database tables) with typed fields — text, number, relation, file, enum, and 18 more. EmuView generates CRUD endpoints with filtering, sorting, pagination, and full-text search automatically. Add auth with email/password, OAuth, or magic links. Upload files to R2 with presigned URLs. Build automation flows with visual triggers, webhooks, and 38 built-in operations. Control access with 6 built-in roles or custom RBAC policies at the row and column level. Store and query geospatial data with native GeoJSON field types and S2-inspired spatial indexing.
Collections & API
23 field types, instant CRUD endpoints, filtering, sorting, search
Authentication
Email, OAuth, magic links, 2FA, API keys, session tokens
File storage
Direct-to-R2 uploads, auto-thumbnails, 5 GB default quota
RBAC
6 built-in roles, custom roles, row & column level security
Real-time
SSE streams for dashboards, WebSocket via Durable Objects
Automation
Event triggers, cron, webhooks, AI ops, email — 38 operations
Geospatial
Point, LineString, Polygon fields, nearby search, bbox, within/intersects/contains queries
How it compares
EmuView occupies a similar space to other Backend-as-a-Service platforms, but with a key difference: it runs on Cloudflare's edge network, not a single-region server cluster.
| Feature | EmuView | Supabase | Firebase | PocketBase |
|---|---|---|---|---|
| Runtime | Cloudflare Workers (edge) | Postgres (single region) | Cloud Functions (regional) | Go binary (self-hosted) |
| Database | D1 (SQLite at edge) | PostgreSQL | Firestore (NoSQL) | SQLite |
| Cold starts | None | Minimal (warm pools) | Yes (can be 1–3s) | None (always-on) |
| Auto-generated API | Yes (REST) | Yes (REST + GraphQL) | Yes (SDK-wrapped) | Yes (REST) |
| Auth methods | Email, OAuth, magic link, 2FA | Email, OAuth, magic link | Email, OAuth, phone, anon | Email, OAuth |
| Real-time | SSE + WebSocket | Postgres subscriptions | Firestore listeners | SSE |
| File storage | R2 (S3-compatible) | S3-compatible | Cloud Storage | Local disk |
| Automation / workflows | Visual builder, 38 ops | Edge Functions (manual) | Cloud Functions (manual) | Hooks (basic) |
| Self-hosting | Yes (your Cloudflare account) | Yes (Docker) | No | Yes (single binary) |
| Vendor lock-in | Low (SQLite + R2) | Low (Postgres) | High (proprietary) | None |
| Free tier | Generous (Workers free plan) | 2 projects, 500 MB DB | Spark (generous) | Self-hosted (free) |
Comparison reflects typical configurations as of 2025. Each platform has unique strengths — this table is a starting point, not a definitive ranking.
Geospatial features
EmuView includes a built-in spatial engine that works natively with D1 — no external database or PostGIS extension required. Store GeoJSON geometries, run proximity searches, and filter by bounding box or polygon, all from the same REST API you use for everything else.
Geo field types
Point, LineString, Polygon, and generic Geometry fields with GeoJSON storage and auto-centroid computation
Nearby search
_geo_near operator with S2 cell covering + Haversine refinement. Auto-selects
precision level (75m or 1.2km)
Bounding box
_geo_bbox filter for map viewport queries. Centroid + stored BBOX overlap detection
for lines and polygons
Within & intersects
_geo_within (point-in-polygon) and _geo_intersects with Turf.js
post-filtering for exact geometry tests
Contains
_geo_contains finds records whose polygon contains a query geometry, using
S2 coverings subquery + Turf.js
Distance sort
_geo_distance for ORDER BY distance — great for "nearest stores" listings with
cursor pagination
How the spatial engine works
EmuView uses a simplified S2-inspired cell indexing scheme based on Morton/Z-order curve
bit-interleaving. Each geo field gets dual indexes at level 13 (~1.2km precision) and level
17 (~75m precision), enabling efficient B-tree BETWEEN queries on SQLite. Coarse results are
refined with Haversine distance or Turf.js boolean operations (point-in-polygon, intersects,
contains) for exact spatial accuracy. Complex geometries (lines, polygons) also get S2 covering
ranges stored in a dedicated _s2_coverings table for efficient overlap queries.
Advanced debugging for automations
Building automation flows is powerful, but debugging them when something goes wrong is critical. EmuView provides a full observability stack for every flow run — from step-level execution traces to AI-assisted error analysis.
Test runs (dry-run)
Execute flows with mock trigger data before publishing. No side effects — see exactly what each step would do
Step-by-step execution logs
Every step records status, resolved input, output, error, duration, and log lines. Stored per-run for historical analysis
Debug inspector
Visual inspector with expandable step entries showing input/output/error, live status badges, duration stats, and auto-scroll
Run history
Browse past runs with status filtering, pagination, and drill-down into individual step logs. Delete old runs to manage storage
AI-assisted debugging
Send flow definition + failed run context to AI for analysis. Get suggested fixes, field corrections, and even complete flow replacements
Conditional execution
Per-step condition evaluation with skip logging. Error handling strategies: stop, continue, retry, or fallback per operation
Debug context generation
When sending a failed run to AI for analysis, EmuView generates a structured debug context including: flow overview (status, trigger, collections, options), full run results (step status, resolved inputs, outputs, errors, logs), and an operations reference (config fields, descriptions for used and available operations). This gives the AI model everything it needs to suggest targeted fixes — not just "check your config."
Why Cloudflare?
EmuView is built natively on Cloudflare's developer platform. This isn't incidental — it shapes every architectural decision, from where your data lives to how fast your API responds.
Global edge by default
Your API runs in 300+ Cloudflare locations. Users in Tokyo, Frankfurt, and São Paulo all get sub-50ms latency without any configuration.
Zero cold starts
Workers use V8 isolates, not containers. There's no boot time — your API responds in milliseconds on the first request after any idle period.
Generous free tier
100k requests/day, 5 GB R2 storage, 10 MB D1 databases — all on the free plan. No credit card required to start, no surprise bills at low traffic.
You own the infrastructure
Self-host EmuView on your own Cloudflare account. Your data, your billing, your compliance. No third-party SaaS has access to your production database.
Integrated storage stack
D1 for relational data, R2 for files, KV for sessions, Durable Objects for real-time — all from one provider with unified billing and zero integration glue.
Enterprise-grade security
Cloudflare's DDoS protection, WAF, and TLS are built in. Your API inherits the same infrastructure that protects millions of websites.
Known limitations
- D1 is SQLite, not PostgreSQL. If you need advanced features like stored procedures, partial indexes, or PostGIS, you'll miss them. D1 is excellent for most app workloads but not a drop-in Postgres replacement.
- Workers CPU time limit. Each request gets up to 30s of CPU time on the paid plan (10ms on free). Long-running batch jobs or heavy data processing need to be chunked or offloaded to a queue.
- D1 row size limits. D1 inherits SQLite's 1 MB max row size. If you're storing large blobs, use R2 instead of a database column.
- No native WebSocket from Workers (yet). Real-time WebSocket uses Durable Objects, which adds a small complexity overhead. SSE works directly from Workers.
- Region-specific features. Some Cloudflare features (e.g. D1 read replicas, R2 location hints) are still maturing. The platform evolves rapidly but not every feature is available in all regions yet.