Mortar roadmap

Living document. Updated each session. M-series aligned with Keel so the two infrastructure products ship in lockstep.

M = Milestone. Mortar/Keel 用 M 编号区分 launch 成熟度;区别于 Fabric 的 V 编号(V = 项目类型 / project type)。

Status legend: [ ] not started, [~] in progress, [x] done.

M0 historical 内容合并到 M1 § Historical context;产品对外编号从 M1 起.


M1(公开 launch — ~3 个月)—— Mortar Cloud beta

Historical context — 内部 dogfood 阶段(pre-M1,2025-2026.05)

Internal use only. 6 primitive (compute / database / cache / storage / network / function) × 5 feature (auth / data / files / realtime / usage) 骨架;backing Fabric’s AI bundle runtime. No public Mortar Cloud brand yet.

  • ✅ 6 primitive interfaces + LocalDisk + Postgres + self-hosted Redis impls
  • ✅ 5 feature CRUD endpoints
  • ✅ Per-project JWT + admin API keys
  • ✅ Usage credit ledger
  • ✅ Plan gate (Tier 1-5)

M1 — first public release

M1 is the “first time anyone outside appunvs can use Mortar”. All launch-critical infrastructure + go-to-market surface. Most items already shipped this session; remaining are operational (备案 / 商户号 / 部署运行手册).

Mark items already shipped this session [x]; new items still [ ]:

Code

  • Project lifecycle endpoints (CRUD + JWT-scoped account model)
  • Account model (mortar_accounts + signup/signin/me)
  • End-user JWT middleware
  • Auto top-up real path + WeChat Pay + Alipay providers
  • Health probes (live / ready)
  • Network primitive byte counting (EgressMeter middleware)
  • OSS signed-URL egress accounting
  • Compute backends (Aliyun FC + Tencent SCF Deploy/Delete/Logs)
  • Cache backends (local + redis)
  • Storage OSS + COS + LocalDisk
  • Rate limiting (per-API-key + per-IP via cache primitive)
  • Audit log table + hooks
  • Security headers middleware
  • TypeScript SDK
  • Mortar CLI (sole control-plane client — no web admin UI)
  • Native SDKs scaffold (Swift / Kotlin / Dart)
  • OpenAPI 3.0 spec (1360 lines, 37 operations)
  • AI on-call monitoring design (mortar/docs/monitoring-ai-employee.md)
  • Status page (GET /status, self-contained HTML)
  • API key LRU cache
  • Redis pub/sub broker for realtime multi-instance
  • Compute logs API (SLS + CLS readers)
  • Multipart upload for storage
  • comms primitive — 7th cost dimension (email + sms as two ledger resources at distinct unit prices; local dev backend + aliyun adapter reusing signACS3; aliyun DirectMail TODO)
  • Phone-OTP login (/v1/{tenant}/auth/phone/{start,verify}) composing comms.sms + cache + AppUser JWT
  • Email verification + password reset (/v1/{tenant}/auth/email/ verify/*, /v1/{tenant}/auth/password/reset/*) on the same cache + comms.email substrate
  • Send-side throttle: per-recipient cooldown (60s) + per-recipient / per-tenant daily caps via cache.IncrTTL (anti-bombing for sms + email)
  • AppUser schema: phone + email_verified fields, partial unique indexes on (tenant_id, email) / (tenant_id, phone) WHERE col <> '' so password users and phone-OTP users coexist
  • Account-scope long-lived PATs (mtr_pat_*) for CI / headless, MORTAR_ACCOUNT_TOKEN env var override on the CLI side (analogous to SUPABASE_ACCESS_TOKEN)

Operational (non-code, lawyer/operator-required)

  • ICP 备案 + 公安备案 + 税务登记
  • WeChat Pay / Alipay merchant accounts (production credentials)
  • Production monitoring stack (Aliyun SLS + 阿里云监控 + Grafana)
  • Phase 1-6 infrastructure (VPC / RDS / Tair / OSS / FC / ALB / domain)
  • Privacy policy (GB/T 35273 compliant)
  • Terms of Service
  • Data Processing Agreement (enterprise)
  • SLA published (99.9% target)
  • Documentation site (uses Fabric dogfood)

M2(Production hardening — ~3 个月)

Post-launch polish — what customers喊 in the first 2 weeks of real traffic. Doesn’t block M1 ship.

  • OSS access-log → ledger pipeline (precise per-object egress accounting)
  • Per-project OSS bucket prefix scheme (clean billing query path)
  • PG extension recommendations doc (pgvector / pg_partman / TimescaleDB)
  • AI monitor playbook library (10+ pre-built runbooks for common incidents)
  • Native SDK feature parity — Swift / Kotlin / Dart catch up to TypeScript
  • Performance SLO doc + dashboards
  • Realtime multi-region prep (test cross-replica subscribe at 10k subs scale)
  • Supabase migration cookbook (docs only; the import tool was dropped)
  • OpenAPI → SDK auto-gen pipeline (openapi-generator wrapper for non-TS langs)
  • mortar init interactive onboarding wizard (CLI walk-through: login → create project → mint admin key → first SDK call)

M3(功能完整化 — ~6 个月)

扩展 Mortar 的功能广度,覆盖现代 BaaS 的标准能力(cron / FTS / vector / queue)。每个 item 是 1-2 sprint 工作量; 可以并行。

  • Edge function cron triggers (compute primitive extension)
  • Custom domains (user plugs their own domain into Mortar)
  • Full-text search (pg_search or Meilisearch sidecar)
  • Vector embeddings + RAG cookbook (pgvector helpers)
  • Queue / background jobs (pg-boss or sidekiq equivalent)
  • Realtime presence + broadcasts (separate channel from row change) — done: realtime.channel() (broadcast + presence) over SSE+POST, 4-SDK; completes the Supabase Realtime triad

M4(Scale + multi-region — ~12 个月)

Customer growth-driven; lights up when first big customer signs.

  • Database branches (git-like Postgres branching, PR-per-database)
  • Read replicas (config + connection pool routing)
  • Per-project dedicated RDS (Large+ tier; isolates noisy neighbors)
  • Multi-region (China-North + China-South + Singapore international)
  • BYOC (Bring-your-own-cloud — customer’s AWS hosts data, Mortar binary is stateless control plane)
  • Cross-cloud failover (Aliyun ↔ AWS dual deploy for enterprise)
  • AWS backends (backend/aws/{s3,lambda,stripe}.go — international expansion; managed Redis via MORTAR_CACHE_REDIS_URL pointed at ElastiCache, no separate backend needed)
  • Bug bounty program (HackerOne or 自建)

M5(Enterprise — shared pack with appunvs + Keel)

⚠️ M5 is NOT Mortar-only. AppUnvs / Mortar / Keel ship a single enterprise pack — one Helm chart, one SSO gateway, one RBAC schema, one SLA contract, one audit log. See keel/docs/roadmap.md § M5 for the shared design.

Mortar-specific items inside the shared pack:

  • Per-customer SSO mapping to mortar_accounts (account_id ←→ SAML subject)
  • RBAC role: mortar.project.owner / mortar.project.member / mortar.usage.viewer etc.
  • Audit log emit to shared SIEM stream (Splunk / SLS / Elastic)
  • Private deploy: Mortar Helm chart variant included in appunvs-enterprise umbrella chart
  • SOC 2 / ISO 27001 controls (data encryption at rest, key rotation, retention policy)
  • Bring-your-own-encryption-key (KMS integration)
  • HIPAA / 等保 2.0 Level 3 compliance documentation

For SSO / RBAC / audit / monitoring / SLA detail, see Keel M5 (same content).


Decisions still open

  1. CLI distribution — pure npm vs single static binary vs both? Recommendation: both — npx @mortar/cli for try-it-once + mortar global binary for daily use.
  2. OpenAPI hand-written vs auto-gen — hand-written is simpler today, auto-gen scales when API grows past ~30 endpoints. Recommendation: hand-written for M0, switch when pain.
  3. Native SDK release order — Swift first (iOS Mortar Cloud customers), then Kotlin, then Dart? Or all 3 parallel? Depends on hiring.
  4. Per-project OSS bucket vs shared bucket+prefix — buckets are easier for billing, prefix is easier for ops. Recommendation: shared bucket + prefix (one bucket, simple lifecycle policies).

Already done

See feat/mortar-init git log; high-level summary:

  • W1-W6: skeleton → auth → data → storage → realtime
  • Hexagonal refactor: 6 primitives + features + backend layout
  • W7.a-d: pricing model + credit ledger + plan.Gate + dashboard endpoint
  • Egress→Network rename
  • Network usage recording (event-time)
  • Hourly ticker (baseline + storage + cache_overage)
  • Payment package moved out of primitive/ to internal/payment/
  • 50+ unit tests + 1 storage roundtrip + 2 RLS integration tests

14+ commits on feat/mortar-init (push blocked by GitHub account suspension; will land when restored).