[data-reveal]{opacity:1!important;transform:none!important}
Project setup
Building

Project setup

Set up a normal AntelopeJS project that loads the DMS as a dependency and registers its own pages.

Use the Quickstart to run a new application from the demo template. This reference explains the project layout, module configuration, and lifecycle when you adapt that template or add the DMS to an existing AntelopeJS application. Your application owns its pages, data, and business logic; the DMS provides the dashboard, authentication, and component system.

If instead you package a reusable extension to ship to other projects, see Distributable module. It uses the same page and component APIs — only the packaging differs.

Project layout

A typical project:

my-app/
my-app/
  antelope.config.ts        # THE project: which modules to load (incl. the DMS) and their config
  package.json              # deps: @antelopejs/dms + @antelopejs/dms-frontend + the stack
  src/
    index.ts                # your project's module: construct/start/stop lifecycle + AddFrontendModule
    pages/                  # @RegisterPage classes                         → Pages & components
    data-api/               # DataControllers (TableViews attach on pages)  → Data controller
    data-types/             # custom DataTypes                              → Data types
    permissions/            # RegisterPermission                            → Auth & permissions
    db/                     # @RegisterTable models / schema
    routes/                 # @Controller HTTP routes                       → Pages & components
    services/               # your business logic
  frontend-vue/             # OPTIONAL — your own frontend layer (custom Vue) → Frontend layer

antelope.config.ts — loading the DMS and the stack

The config declares which modules to load and their per-module configuration. Your own code loads as a module with a local source (source.type: "local") — the module key (local below) is just a name; pick any. Use the template's complete configuration for the current package ranges and infrastructure. The example below shows only the local-module entry to merge into that configuration; it is not a standalone runnable stack.

antelope.config.ts
import { defineConfig } from "@antelopejs/interface-core/config";

export default defineConfig({
  name: "my-app",
  modules: {
    local: {
      source: {
        type: "local",
        path: ".",
        watchDir: ["src"],
        installCommand: ["pnpm install", "pnpm build"],
        reloadCommand: "pnpm exec tsc",
      },
      config: {
        /* your project's Config — flows to construct(config) in src/index.ts */
      },
    },

  },
});

Key points:

  • The DMS needs an API module (HTTP server), a database (e.g. mongodb), and auth-jwt; wire each in modules. Redis is optional for a single development instance. Table decorators come from the @antelopejs/interface-database-decorators library — no dedicated module is required by the demo's current stack.
  • The DMS's own config you touch most: apiBaseUrl, clientBaseUrl, and auth.jwtSecret (the DMS's own session-token signing secret — set a strong value in production). Every key, every default, and the auth/htmlRender/realtime blocks are in Configuration.
  • The DMS auto-registers its base dashboard layer — the core UI (shell, login, component vocabulary) that renders standard pages. A frontend module is included by its AddFrontendModule call, not by config (see Frontend layer). A pages-only project needs no frontend module of its own.

Your project's lifecycle (src/index.ts)

A project is itself a module — the lifecycle (construct, start, …) is a framework concept, covered in Creating a module. The side-effect imports run your @RegisterPage/@RegisterDataType/etc. decorators, and construct(config) receives the local module's config.

src/index.ts
import "./pages"; // @RegisterPage
import "./db"; // models / schema
import "./data-api"; // DataControllers
import "./routes"; // @Controller

export interface Config {
  /* whatever you put under modules.local.config */
}
let globalConfig: Config = {
  /* defaults */
};
export function getConfig(): Config {
  return globalConfig;
}

export function construct(config: Config): void {
  globalConfig = config;
}

A custom frontend module is optional and attached with AddFrontendModule from construct() — see Frontend layer.

What you register (same APIs as everywhere)

Once the project is wired, building the actual admin is identical to the rest of these docs — none of it is project-specific:

You want to…UseDoc
Add a dashboard screen@RegisterPage + PageController, attached to pagesCategory or a CategoryPages & components
Show a table / CRUDDataController + TableViewRoutes / TableViewData controller, Tables
A custom field/column type@RegisterDataType extending DataTypeData types
Custom actions, cross-component reactivity.action(), .watch(), ActionTargetActions & reactivity
Gate pages/routes, define permissionsinterface-dms/auth + interface-dms/guards decorators, RegisterPermissionAuth & permissions
Hooks, notifications, HTML renderinterface-dms/hooks, interface-dms/notifications, interface-dms/html-renderBackend services
Custom Vue in your dashboardyour frontend-vue/Frontend layer

Running

Two coupled processes (full detail in Architecture and Frontend layer):

  • Backend — ajs project dev -w (watch). Most projects also bring up infra (Mongo/Redis) in Docker first, e.g. a dev script of docker-compose up -d && ajs project dev --inspect -w.
  • Frontend — the Vue loader: ajs dms dev. It auto-discovers the backend, so -b <apiBaseUrl> is optional (see Frontend CLI). Projects conventionally expose this as a frontend:dev pnpm script.

In production you build both processes once and launch them from their build artifacts, with production secrets and Redis. Deployment covers the build commands, startup order, and the production checklist.