Open source · MIT licensed

Define once. Reference outward. Validate always.

Appling is a declarative language that describes a business application as one validated model. That text is the single source of truth: Appling checks it, shows it as a living graph you can edit, lets AI propose changes you review, and generates a draft Django or Ash project from it, so people and AI always build from the same model.

Get startednpm i -D @appling/cliRead the docs →

entity Orderaction PlaceOrderVisualizeGenerate codesales.applingbilling.applingsingle source of truth

Architecture

Five layers, one model

Each concept is defined once, in the layer that owns it. References only point down the layers, and modules only see what other modules export.

L5 Experience

How people reach it

page · navigation · flow · messages

L4 Interfaces

How programs reach it

interface

L3 Application

How capabilities are organized

query · projection · external · usecase

L2 Behavior

What can happen

event · action · machine · job

L1 Domain

What exists

enum · value · entity · invariant · policy

Cross cutting

Modules, access, evolution

module · role · actor · tenant · migration

How it works

From text to a living graph

Text

Write the model in plain .appling files. The text is the canonical source.

Graph

Parsed and linked across files and modules, every element by its qualified name.

Validated

Layer rules, exports and migrations are checked on every build.

Visualize and generate

Explore and edit the graph in the IDE, review AI proposals, and generate a Django or Ash project, all from the same source.

Toolchain

Every tool reads the same graph

The command line, the IDE, the AI and the generators all work on one validated model and change it through the same edit operations.

@appling/cli

CLI

Check, format, dump the graph, cut releases and generate projects. Exit codes made for CI.

$ npx appling check modelsRead the docs →@appling/ide

IDE

The text and the zoomable graph side by side. Edit in either; every edit is validated and lands as one undoable step.

$ npx @appling/ide modelsRead the docs →@appling/ai

AI

An MCP server for any client and a chat in the IDE. AI changes pass validation and arrive as proposals you review.

$ npx appling-mcp modelsRead the docs →@appling/codegen-django, @appling/codegen-ash

Code generation

A draft Django or Ash project from the model, plus a task registry of everything left for you or an AI to write.

$ npx appling generate --planRead the docs →@appling/model

Releases and migrations

A release snapshots the graph. Later renames and type changes become migration steps that generated projects apply without losing data.

$ npx appling release 1.0.0Read the docs →@appling/lang

Language server

Diagnostics, completion, go to definition, rename, hover and canonical formatting in any editor that speaks LSP.

$ appling-language-server --stdioRead the docs →

Example

One file in, one linked model out

The same sales module, as text and as the graph Appling builds from it.

sales.applingvalid

module sales {
  export Order

  enum OrderStatus {
    draft
    placed
  }

  entity Order {
    reference: String unique
    status: OrderStatus state default draft
  }

  action PlaceOrder on Order {
    requires { reference != "" }
  }

  machine OrderFlow on Order.status {
    transition draft -> placed via PlaceOrder
  }
}

The graph

What people say

Proof from real projects

[CUSTOMER QUOTE: what Appling changed for their team]

[NAME], [ROLE], [COMPANY]

[CUSTOMER QUOTE: a concrete before and after]

[NAME], [ROLE], [COMPANY]

Example repositoryBrowse full models on GitHubalex20465/appling/examples →

Roadmap

One graph, every tool on top

Every tool reads the same resolved semantic graph and changes it through the same edit operations. The graph came first, then the IDE and code generation grew from it in parallel. Every stage below has shipped.

IDE

@appling/ide, @appling/ai

Code generation

@appling/codegen, codegen-django, codegen-ash

Stage 1

Foundation

Shipped

@appling/lang, @appling/model

Semantic graphPlain, serializable nodes and typed edges. Zoom aggregation, such as module to module dependencies, is computed.
Edit operationsAdd, rename, retype, remove and set attribute, each a minimal text edit that is rejected if it fails validation.
Releasesappling release writes a graph snapshot. Edits to released L1 elements append migration steps automatically.
Language serverLangium's LSP services, exported as @appling/lang/lsp.
Expression typingEvery name and type inside expressions resolved, including this, actor and now. An unresolved name is an error.

Done: the CLI dumps the graph of the examples and an edit operation survives fmt unchanged.

Stage 2

A1ShippedIDE

Read only IDE

npx @appling/ide opens the workspace in the browser: an LSP backed editor and the zoomable graph, with selection synced between them.

B1ShippedCode generation

Core

Plan, step runner, map contract, task registry and prerequisite checks behind appling generate.

B2ShippedCode generation

Domain maps

Django and Ash maps for entities, enums, value types, invariants and policies.

Stage 3

A2ShippedIDE

Editing

Edit elements and attributes in the graph. Migration entries appear once a release exists.

A3ShippedIDE

AI

An MCP server for any client plus a chat panel. AI changes pass validation and arrive as reviewable diffs.

B3ShippedCode generation

Behavior to interface maps

Actions, state machines, events, jobs, queries, projections, use cases and interfaces.

B4ShippedCode generation

Tests

Test skeletons for invariants, preconditions, transitions and policies.

Stage 4

B5ShippedCode generation

Registry skill

AI picks open registry entries, implements them, runs the related tests and marks them done.

B6ShippedCode generation

Migrations

makemigrations and mix ash.codegen, fed with Appling rename and retype steps so nothing is guessed as remove plus add.

Stage 5

VS Code extensionShipped
Highlighting, diagnostics and navigation from the bundled language server.
Appling SyncShipped
appling generate --sync merges a fresh generation into the project three ways and keeps your changes.
Reverse engineeringShipped
An AI skill derives an Appling model from an existing application.
More targetsShipped
Go and Rust extensions for the domain and behavior layers.
SimulatorShipped
Reachable states, permitted actors, risks and action runs against sample data.
Experience generationShipped
Pages, navigation and labels as Django views and Phoenix LiveViews.

Get started

Install, check, open, generate

Point the tools at a folder; files that reference each other load as one workspace.

check validates every .appling file and exits with 1 when it finds errors.

fmt rewrites files into canonical form. A second run changes nothing.

@appling/ide opens the text and the graph side by side in your browser.

generate writes a draft project for every target in appling.config.json.

Write your first model →

terminal

# add the CLI to your project$ npm i -D @appling/cli# validate every model$ npx appling check models# open the IDE on http://127.0.0.1:4410$ npx @appling/ide models# preview the generated project$ npx appling generate --plan models