Planuze
Downloads
Open menuClose menu

From data model to backend.You own the code.

Describe what you need, review the proposal, and approve the code before it reaches your project.

Choose a downloadSee the agent
Also forView all
  • Stable release
  • Official download
  • In-app updates

The agent models and generates the code. You approve every diff.

  1. You ask: I need invoices with line items, linked to the customer.
  2. It proposes the model: Two collections, one relation and a listing route.
  3. It applies through the editor: Applied. Both collections are in the module tree.
  4. You approve the diff: 8 files to write. No existing file gets overwritten.
  5. What lands in your project: schema, migration, model, validator. Plain files on your disk: opens in your editor, goes into your commit, runs with Planuze uninstalled.

AI agent

The agent models and generates the code. You approve every diff.

Describe what you need, follow the proposal, and decide what reaches the project.

Illustrative example: conversation and diff approval
  1. 1

    I need invoices with line items, linked to the customer.

  2. 2

    Two collections, one relation and a listing route.

  3. 3

    Applied. Both collections are in the module tree.

  4. 4

    8 files to write. No existing file gets overwritten.

  1. 1

    You ask

    Describe what you need in one sentence.

  2. 2

    It proposes the model

    It organizes the solution before making changes.

    • describe_project
  3. 3

    It applies through the editor

    It turns the proposal into project files.

    • create_collection
    • add_column
    • create_relation
    • set_route
  4. 4

    You approve the diff

    You check everything before saving.

    • generate

You choose the AI provider — including a local one.

What you build

The editor speaks domain, not backend

Collections, columns, relations and routes fit any system with data. The four below are models; the pack you picked generates their backend.

  • Sales and relationships

    Customers, what is in the pipeline, and the history of every talk.

    4Collections you declare

    • customer
    • deal
    • activity
    • note

  • Inventory and catalog

    Products with variants, where each one sits, every movement on record.

    4Collections you declare

    • product
    • variant
    • warehouse
    • stock_movement

  • Scheduling

    Who attends, what they offer, and what is already booked.

    4Collections you declare

    • professional
    • service
    • appointment
    • availability

  • Internal portal

    People, departments, and the requests that need approval.

    4Collections you declare

    • employee
    • department
    • request
    • approval

None of these examples comes ready-made: the pack turns what you declared into code.

Four parts, and the vocabulary comes from the pack

  • Declarative modeling

    Collections, columns and routes become versioned JSON inside the project.

  • Generation with diff approval

    Nothing reaches your disk without a diff you approve.

  • An agent that drives the editor

    It calls the editor’s own operations instead of improvising architecture.

  • Signed packs

    The stack, the vocabulary and the generator come from the installed pack.

From model to disk

You declare the collection. The backend shows up as files.

What you model in the editor becomes ordinary files, ready to review and version.

What you declare

Planuze's collection editor, with a sample collection open.

  1. numberstring
  2. totaldecimal
  3. paidboolean
  4. customer_idstring

The file the editor saves

planuze/api/invoice/schema.json

{ "schemaVersion": 1, "id": "invoice", "name": "invoice", "columns": [ { "id": "c1", "name": "number", "type": "string", "unique": true }, { "id": "c2", "name": "total", "type": "decimal", "precision": 12, "scale": 2 }, { "id": "c3", "name": "paid", "type": "boolean", "default": false }, { "id": "c4", "name": "customer_id", "type": "string", "indexed": true } ], "relations": [ { "id": "r1", "name": "customer", "kind": "many-to-one", "target": { "kind": "collection", "id": "customer" }, "fkColumn": { "kind": "column", "collectionId": "invoice", "columnId": "c4" }, "targetColumn": { "kind": "column", "collectionId": "customer", "columnId": "c1" } } ], "routes": [ { "id": "rt1", "type": "index", "enabled": true }, { "id": "rt2", "type": "store", "auth": true, "enabled": true } ]}

What lands in your project

  1. schema

    Database schema, in the language of the pack’s ORM.

  2. migration

    Versioned migration, from the current state to the new one.

  3. model

    Typed model, with relations already resolved.

  4. validator

    Input validator, derived from each column’s rules.

  5. controller

    Controller carrying the operations of the configured route.

  6. route

    Route registration in the API, ready to take a request.

Plain files on your disk: opens in your editor, goes into your commit, runs with Planuze uninstalled.

From the download to these files

  1. Sign in with an e-mail code, GitHub or Google. A plan and an AI provider can wait.
  2. Install a pack and create the project: you pick the folder on your disk.
  3. Declare the collection and ask for generation: you read the diff, approve it, and the files show up in the folder.
Choose a download

No lock-in

The generated code is yours, and stays yours if you leave

Ordinary source code, with dependencies you already know. There is no layer of ours between your backend and your production.

  1. On your disk, from the very first file

    Generation writes into the directory you picked. No upload, no cloud workspace.

  2. Versionable like any other code

    Declarative files and generated code go into the same commit. Diff, blame and revert work.

  3. You ship it your way

    Container, VM, serverless, whatever pipeline you already run. No infrastructure of ours to go live.

  4. Leaving breaks nothing

    Uninstall it and the project still compiles and runs. You lose the tool, not the product.

What is not in the way

  • No proprietary runtime in production
  • No mandatory call to a server of ours for the backend to work
  • No closed format — the declarative files are readable JSON
  • No database lock-in: the pack picks the ORM, and you pick the pack

Packs

The stack comes from the pack you choose

Choose how the backend is generated without tying the project to one stack.

  1. declarations

    It all starts with the pack

    It brings together the types, relations, routes, and validators you use to model the project.

  2. signatureAlgorithm

    Verified installation

    The signature and every file are checked before the pack is installed.

  3. stack

    Switch stacks with another pack

    Language, database, and ORM change with the pack while your project files stay in place.

  4. distribution

    Publish packs for your team

    Bundle and sign through the CLI without taking the private key off your machine.

Explore available packs and the options included in your license inside the app.

Organizations

An organization is not a shared login

Each person has their own account and their own seat. Every administrative action is recorded with an author and a date.

Clear roles for each person
Owner, admin, and member have their own permissions. Nobody joins automatically through an e-mail domain.
Seats that keep up with the team
Use the seats included in your plan and adjust the quantity as the team changes.
Private packs for the organization
Share packs only with authorized people; access ends when they leave the organization.
History of administrative actions
Invitations, removals, and ownership transfers are recorded with author and date, with CSV or JSON export.

Manage people, seats, and audit records in the organization panel inside Planuze.

Where your data sits, and what the app sends out

Your project stays local. When the app uses the network, you know why.

  1. The project lives in the folder you picked

    You point at a directory and Planuze writes into it: declarations, each collection’s schema, and the generated code. The agent’s history sits under the app’s data folder, also on your machine. There is no cloud workspace.

  2. Keys go to the operating system keyring

    API keys and tokens stay protected by the operating system keyring. If it is unavailable, the app stores no sensitive data in plain text.

  3. You pick the AI provider, a local one included

    Use Anthropic, OpenAI, Gemini, Ollama, or another compatible provider. With Ollama, the conversation stays on your machine; with a remote provider, the app connects directly using your key and no proxy of ours.

  4. There is no usage analytics

    No usage events or usage metrics are collected. Only crash reports are sent, with keys, tokens, and e-mail addresses filtered out.

What leaves your machine, and why
  • Signing in and renewing your session: your e-mail and the access code, or what social login hands back.
  • License verification, every few hours: the license token and the device identifier — not your project.
  • The update check (operating system, architecture, channel and installed version) and the installer itself, when a new version exists.
  • The marketplace catalogue, the docs, and the download of every pack you install — the install record carries the project path.
  • The list of installed packs, when you ask the app to check them for updates.
  • The conversation with the remote AI provider you chose, using your key: it carries whatever the agent read from your project to answer, plus your working directory path. With a local provider, none of it goes out.
  • The contents of one file, if you ask the AI to settle an edit conflict during generation.
  • Your API key, when you test the connection or ask a cloud provider for its model list — that round trip goes through our server.
  • Checkout and subscription: the payment form is Stripe’s, runs inside the app and talks straight to Stripe, its own SDK telemetry included.
  • The crash report, when the app breaks.
  • Whatever you write in the support chat, the attachments you send, and the profile picture you choose.
  • Your account notifications, the Help content and the release notes — plus, if you run an organisation or publish packs, whatever you do on those screens.

A local provider keeps your AI conversations on your machine.

What people ask before downloading

  • Does Planuze replace my backend or generate one?

    It generates one. What comes out is a project you open in your editor, run with the tooling you already have and ship to your own production — Planuze stays out of what you shipped.

  • Will it work with my stack?

    That depends on the available pack. Each pack defines the stack and how code is generated; you choose the one that fits your project in the app.

  • Does generation overwrite code I wrote by hand?

    No. Before any file is written, you review the diff and approve changes file by file.

  • What happens to my model if I switch packs?

    Your model stays versioned in the project. Switching packs changes the stack and how code is generated without losing what you already declared.

  • Do I need to be online to work?

    You can model and generate offline. A connection is used to sign in, verify the license, install packs, and reach a remote AI provider. With a local provider, the agent also works offline.

  • Do I need an account?

    Yes, and it is free: you sign in with a code sent to your e-mail, or through GitHub or Google, and there is no password to create. Picking a plan and setting up an AI provider are steps you can skip and settle later.

  • Do I have to pay to model and generate?

    No. Modeling and generation do not depend on a paid plan. Plans differ in AI agent features, session history, organization seats, and private packs.

  • How does licensing work?

    The license applies to your profile. For teams, the organization holds the seats and controls who can access private packs.

Model one collection and watch the backend show up.

Local install and a free account. Whatever it generates lands on your disk.

Choose the download that matches your machine.

Check the architecture and format when more than one option is available.

Other update channels

Beta and Canary give you new features earlier, but may be unstable. Use them when you can return to the stable release.

BetaNearly finished features, now in final validation.

CanaryThe latest changes, with a higher chance of instability.