Your framework, your components, compiled to static assets.
Metadata-driven backend platform
Define the entity. The backend follows.
Pikbase is a metadata-driven backend platform: define entities once, then operate governed APIs, functions, workflows, auth, and storage from one console.
Publish your frontend as static files anywhere. Pikbase runs the governed data, auth, functions, workflows, and documents behind it.
Invoice
string✓relation✓decimal✓datetime—Static frontend
Direct Core client
Governed backend
Publish anywhere
One deployment
Ship the frontend. Skip the backend build.
A browser application can be published as static files and call its Pikbase tenant directly through the Core client without an app-owned API proxy or ORM server.
Read the static application guideCDN, object storage, or an edge-pages provider.
Data, authorization, files, functions, libraries, and workflows.
No app serverNo API proxy or ORM process to provision beside the frontend.
Backend enforcedPermissions stay authoritative in Entity Service, not in client-side interface code.
Extend in placeCustom code publishes to the tenant runtime instead of a separate server stack.
The data foundation
Build the application before you build custom backend code.
Entity Service handles the governed reads and writes behind data-driven applications. Add custom logic only where the business process needs it.
Read the graph
Nested filters, related includes, search, aggregates, grouping, sorting, and pagination in one query model — identical from TypeScript, the CLI, and agent tools.
Write the graph
Send related objects and arrays in one nested save. Records are created or updated together and the transaction rolls back if any part fails.
Enforce at the data layer
Entity, row, and property permissions travel with the model and are applied to whoever is calling — your application, your team, or an authorized agent.
One query model
The same query, wherever it is written.
The fluent builder and the JSON the CLI and agent tools accept describe the same request against the same definition.
const orders = new QueryParams<Order>("Order")
.filter("status", "open", QueryFunction.Equals)
.include(new IncludeQuery<Customer>("customer").select(["id", "name"]))
.self.sortBy("createDate", QuerySortType.Descending)
.take(25)
.returnCount();
const page = await entityService.query(orders, token, tenantCode); gsb call query --raw --input '{
"queryParams": {
"entDefName": "Order",
"filters": [{ "col": { "name": "status" },
"val": { "value": "open" },
"function": 0 }],
"count": 25
}
}' One control plane
Every backend capability. One visible system.
Model once
Database
Query and transactionally save related data through one permission-aware entity contract.
Control access
Auth
Enforce identity, tenancy, and record-level authorization at the data layer instead of in the interface.
Run logic
Functions
Add tenant-resident logic and shared libraries where data operations are not enough.
Coordinate work
Workflows
Describe durable, inspectable processes instead of hiding state in glue code.
Deliver content
Documents
Turn governed multilingual content into stored files, PDFs, and email sent under your own identity.
Work with agents
Assistant
Give a coding agent the same contract as your team, bounded by the same permissions.
Built for how software gets made now
One contract. Console, CLI, and MCP.
Use the console when you need visibility, documented commands when you need speed, and MCP when your coding agent needs the same entity definitions, functions, and workflows your team works with — under your permissions, not a copy of your data.
Explore agent access$ gsb tools --read-only → inspect what an agent can reach before connecting it $ gsb entities get Invoice ENTITY Invoice FIELDS 4 STATUS published $ gsb query Invoice --limit 3 → applying tenant permissions ✓ 3 records
Build from the contract
Define it once.
Operate it everywhere.
Start with the model, then keep every operation visible as your backend grows — for your team and for the agents working alongside it.