Platform Features
Megapodes is the governed AI application platform: a local AI builds your business systems as validated configuration — never code — every change passes a human approval gate, and the entire platform runs on your infrastructure.
Builder AI: Natural-Language Application Generation
A build-time agent — LangGraph orchestration over a local LLM via Ollama — converts natural-language requirements into a complete application specification. It decomposes work into ordered tasks, validates each artifact, and stops at a human approval gate before any change is applied. Because the agent emits schema-validated configuration and never executable code, it cannot inject arbitrary logic; every proposal is schema-checked and dry-run before you approve it.
Ordered task planning: collections, fields, roles, pages, and workflows decomposed into dependency-ordered tasks.
Constrained output: every artifact must pass Zod schema validation and business-rule validation before it can enter a changeset.
Bounded repair loop: validation failures are retried at most three times, then escalated to a human — never silently forced through.
Changeset review: related mutations are grouped into a single changeset for one auditable approval.
Checkpointed sessions: build sessions persist state and resume after a server restart.
Knowledge grounding: proposals grounded in your uploaded glossaries, data dictionaries, and process manuals.
Adversarially tested: attempts to skip the approval gate or induce destructive behavior are rejected server-side.
// Build session checkpointed
✦ Agent: Decomposing request...
Task 1/5: Collections
→ emit CollectionSpec(customers)
→ Zod schema validation ✓
→ business rules ✓
→ dry-run ✓
Task 2/5: Relations
→ emit FieldSpec(deals.customer_id)
→ type: belongsTo → customers
→ Zod schema validation ✓
→ dry-run ✓
Task 3–5: Roles, Pages, Workflows
→ all validated ✓
→ all dry-run ✓
✦ Changeset ready: 14 changes
12 safe · 2 destructive (individually confirmed)
[ Approve & Apply 14 Changes → ]
// AI Employee: "Deal Analyst"
// Role: Analyst · permission-bound
User: Summarize Q3 deals
✦ Employee: Reading deals...
→ permissions: role = Analyst
→ RLS filter: app_id = acme_crm
→ field mask: excludes salary
✦ Result:
✓ 47 deals analyzed for Q3
✓ 12 deals identified as at-risk
✓ Total pipeline: $2.4M
✓ 3 deals stalled for more than 30 days
// Source: 47 records (deals collection)
// Audit: run #a3f2
[ Ask follow-up question → ]
Runtime AI Employees: Role-Bound Data Assistants
AI Employees operate inside your running applications with data-only tools: read, summarize, extract, classify, fill forms, and answer questions. They inherit the exact permissions of the role they run under — the same three enforced authorization layers as human users — and are hard-denied the build surface server-side. The build plane and the runtime plane cannot cross; this boundary is tested adversarially.
-
Data-only tool surface: Read, summarize, extract, classify, fill_form, and answer — no structural mutations.
-
Grounded answers: RAG over pgvector knowledge bases with cited sources.
-
Deployable anywhere: Embedded beside blocks, as workflow nodes, or in an inbox.
-
Permission inheritance: Role ACL, PostgreSQL Row-Level Security, and field masking apply identically to AI and human users.
-
Complete audit trail: Every AI Employee action is written to the append-only audit log with
actor_type ai_employee. -
Hard boundary: The build surface is denied server-side — an AI Employee cannot create or alter application structure.
Microkernel Plugin Architecture
Every capability registers with the kernel through typed extension registries: field types, block types, workflow nodes, auth providers, data-source drivers, and AI tools. Plugins are npm packages with a manifest and a managed lifecycle, and they extend the platform without modifying the core. The built-in features are themselves plugins — the architecture is proven by its own construction.
- Kernel registries: field types, block types, workflow nodes, auth providers, data-source drivers, and AI tools.
- Managed lifecycle: install, enable, disable, and remove plugins cleanly and reversibly.
- Declarative manifest: each plugin declares what it registers and the permissions it requires.
- Dogfooded design: built-in capabilities ship through the same registries as third-party plugins.
- Plugin SDK: typed interfaces for building, testing, and packaging your own extensions.
// Plugin manifest
{
"name": "@acme/custom-fields",
"version": "1.0.0",
"registers": [
"fieldType",
"blockType"
],
"permissions": [
"collections:read"
],
"migrations": [
"001_init.sql"
]
}
// Lifecycle
✓ install → enable → active
✓ disable → remove
// Extension points
✓ fieldType · blockType · workflowNode
✓ authProvider · dataSourceDriver
✓ aiTool · aiEmployeeTool
[ Install & Enable Plugin → ]
// Data source registration
Source: erp_database
Kind: postgres (external)
Credentials: envelope-encrypted
// Introspection
✦ Connector: introspect(erp_database)
✓ Found 23 tables
✓ orders → collection erp_orders
✓ products → collection erp_products
✓ customers → collection erp_customers
// Isolation
✓ main_source: PostgreSQL RLS enforced
✓ erp_database: own credentials
✓ isolated from main-source RLS
[ Connect External Source → ]
External Data Sources: PostgreSQL, MySQL, REST
Connect existing PostgreSQL and MySQL databases and REST APIs as first-class, isolated data sources. Megapodes introspects schemas automatically and maps external tables to collection metadata; external data is never materialized into the platform database, and external sources never inherit or bypass main-source Row-Level Security.
- Drivers: PostgreSQL, MySQL, and REST delivered through the data-source driver registry.
- Schema introspection: external tables imported as collection metadata, never copied as data.
- Envelope encryption: credentials are encrypted with a per-source data key wrapped by a KMS-managed key, and never persisted in plaintext or logged.
- Strict isolation: external sources never inherit or bypass main-source PostgreSQL Row-Level Security.
- Capability scoping: read-only or read-write access declared independently for every data source.
- SSRF protection: REST sources are constrained by outbound allow-lists and request timeouts.
Workflow Engine with Transactional Event Delivery
A visual workflow builder for production automation. Workflows are triggered by data events, schedules, webhooks, or manual actions, and compose branching, looping, record operations, HTTP calls, sandboxed scripts, approvals, notifications, and AI Employee steps. Events are emitted only when the underlying data change commits, and every execution is replayable node by node.
- Node types: branch, loop, delay, create, update, delete, query, aggregate, HTTP, expression, script, approval, notify, and AI Employee nodes.
- Triggers: data events, schedules, webhooks, and manual actions initiate workflow execution.
- Transactional delivery: events are emitted only after the data change commits, preventing phantom triggers.
- Sandboxed scripts: workflow JavaScript runs in an isolated process with no network, filesystem, or process access.
- Replayable executions: complete execution history with per-node inputs and outputs for auditing and debugging.
- Permission-aware jobs: PostgreSQL Row-Level Security applies to background and scheduled work exactly as it does to interactive users.
// Workflow: deduct_inventory
Trigger: order.created
✦ Workflow: Starting execution...
✓ Query items from order
✓ Loop through order items
✓ Update product.stock (-qty)
✓ Evaluate branch: stock < 10 ?
→ Yes → Notify "Low Stock"
→ No → Complete workflow
// Execution #e4f1
✓ Status: Completed
✓ Nodes executed: 7
✓ Replay: Available
[ View Execution Replay → ]
// Three-layer authorization
Layer 1: Role ACL
role: Sales Rep
permissions:
customers: view, create, update
deals: view, create, update
(delete: ✗ denied → 403)
// PostgreSQL Row-Level Security
Layer 2: PostgreSQL RLS
SET LOCAL megapodes.app_id = 'acme'
SET LOCAL megapodes.user_id = 'u123'
SET LOCAL megapodes.role_id = 'r456'
→ RLS policy filters rows
→ cannot be bypassed (no BYPASSRLS)
// Field masking
Layer 3: Field masking
customers: visible [name, email]
masked: [salary, internal_notes]
row_scope: owner = currentUser
✓ All enforced server-side
✓ AI obeys the same 3 layers
Security: Three Enforced Authorization Layers
Authorization is enforced server-side in three layers: role-based ACL, forced PostgreSQL Row-Level Security on every main-source tenant table, and field-level masking applied in SQL. Denials fail closed with a 403. Every structural mutation is gated, and every AI action is audited. These controls are designed in alignment with ISO 27001 access-control requirements, GDPR and India’s DPDP Act 2023, and SOX ITGC change-management and audit-trail expectations — not certified, but built to support your compliance program. See the full architecture in the Trust Center.
- Role-based ACL: roles map permissions across resources, actions, fields, and data scopes.
- PostgreSQL Row-Level Security: enforced on every main-source tenant table. The application role is never granted BYPASSRLS, ensuring policies cannot be bypassed.
- Field-level masking: field masks and row filters are applied directly in SQL during query generation.
- Session context lifecycle: SET LOCAL is applied per transaction and automatically cleared when the transaction ends, preventing connection-pool leakage.
- Append-only audit log: records who, what, when, full diffs, and approvers for every gated mutation and AI action.
- Authentication: argon2id password hashing, short-lived rotating JWTs, OIDC-ready SSO, and optional multi-factor authentication.
Signed Configuration Bundles: Dev → Test → Prod
Export an entire application as a versioned, cryptographically signed bundle and promote it across environments with a governed path: diff and dry-run, human approval, then idempotent apply. Secrets are excluded from bundles and rekeyed in the target environment, so credentials never travel with configuration.
- Complete snapshot: collections, fields, relations, pages, blocks, workflows, roles, permissions, data sources, plugins, AI Employees.
- Signed bundles: cryptographic signatures verified on import.
- Secrets excluded: credentials are excluded or rekeyed; re-entered in the target environment.
- Diff and dry-run: every added, changed, and removed item is reviewed before apply.
- Idempotent apply: re-importing a bundle creates no duplicates.
- Vertical packs (roadmap): hospitality, contact-center, CRM, and edtech bundles.
// Config export
POST /api/v1/apps/{id}/config/export
→ bundle.json (signed, versioned)
→ secrets: excluded
→ signature: attached
// Import to production
POST /api/v1/apps/{id}/config/import
→ diff: +2 collections, ~1 workflow
→ dry-run: safe
→ signature: ✓ verified
POST .../import/{planId}/apply
→ idempotent apply
→ audit_log: recorded
// Promotion path
Dev → Test → Prod ✓
// Knowledge Base: "Data Dictionary"
scope: build ✦
documents: 4
chunks: 142
// Ingestion pipeline
upload PDF → queued
→ chunking → 142 chunks
→ embedding (nomic-embed-text)
→ ready
// Build agent retrieval
✦ search_knowledge("customer fields")
→ 5 chunks retrieved
→ artifacts grounded in:
"customer.status = active|churned"
"deal.value in USD"
// Untrusted context
chunks inform content
chunks cannot authorize
chunks cannot bypass gates
Knowledge Bases: RAG with pgvector, Governed by Design
Upload domain documents — glossaries, data dictionaries, process manuals, legacy system exports — to ground both the Builder AI’s proposals and AI Employees’ answers. Embeddings are generated locally via Ollama (nomic-embed-text) and searched with pgvector. Retrieved content informs output; it never authorizes mutations and never bypasses the approval gate.
- Scoped knowledge: employee-scoped (RAG for AI Employees), build-scoped (grounds the Builder AI), or both.
- Asynchronous ingestion: queued → chunking → local embedding → ready.
- Semantic search: pgvector similarity search over chunked document embeddings — entirely on your infrastructure.
- Untrusted context: retrieved chunks inform content but never authorize mutations or bypass approval gates.
- Injection-resistant: instructions embedded in uploaded documents still face schema validation and the human approval gate.
Air-Gapped & Sovereign Deployment
Megapodes is sovereign by construction. Inference runs on a local LLM via Ollama on your own hardware; there is no cloud AI dependency and no cloud fallback — if the local model is unavailable, AI features fail closed rather than routing data elsewhere. The platform deploys with Docker on your infrastructure, including fully disconnected networks, and environments are promoted with signed configuration bundles.
- Local inference: chat and embedding models run via Ollama on a GPU host you control (~8GB VRAM guidance; CPU-only possible but slower).
- Fail-closed AI: no cloud fallback exists — prompts, documents, and data never leave your network.
- Air-gap capable: Docker deployment operates on fully disconnected networks.
- Signed promotion: dev → test → prod via signed, secret-free bundles with diff, dry-run, and approval.
- Tenancy and erasure: schema-per-app isolation in PostgreSQL; per-app backup and restore; GDPR- and DPDP-aligned erasure as a per-app schema drop.
- Supply chain: locked dependencies, minimum release age, and an SBOM produced at build.
// Deployment: your network only
Inference: Ollama (local GPU host)
chat model → local
embeddings → local (nomic-embed-text)
cloud fallback → none (fail-closed)
// Runtime
Runtime: Docker, self-hosted
server/worker replicas: stateless
cache: Redis-coordinated
queues: BullMQ
// Network egress
Network egress:
AI traffic → 0 external calls
REST sources → allow-listed only
air-gapped mode → supported
// Promotion
Dev → Test → Prod
via signed bundles (secrets excluded)
MCP Endpoint: Build with External AI Agents
Every build-time capability is exposed as a schema-typed tool over a Model Context Protocol (MCP) Streamable-HTTP endpoint. External coding agents such as Claude Code build applications through typed tools only — with no direct database access and no path around the approval gate.
Streamable HTTP
MCP endpoint at /mcp built on @modelcontextprotocol/sdk. Every tool call validates its arguments against the same Zod artifact schemas and executes under an injected role.
Tool Surface
inspect_system, create_collection, add_field, configure_page, create_block, create_workflow, grant_permission, register_data_source, install_plugin, configure_ai_employee, search_knowledge, run_migration_dryrun, apply.
Gated Apply
Apply refuses to execute without a passed dry-run and an approval token, and every call is permission-enforced. An external agent builds a complete application through tools only — no database access, no gate bypass.
See governed AI application building in your environment
Walk through the platform with our team, or review the full documentation and deploy on your own infrastructure.
Self-hosted — your data never leaves your network · Every change human-approved and audit-logged · SSO/OIDC available · We support your security review.
The governed AI application platform. A local AI builds business systems as validated configuration, every change is human-approved, and it all runs on your infrastructure.