Login

Create your own package Last updated: 07. May 2026

Build a reusable package — schemas, templates, code and content bundled into a workspace folder that can be installed into other workspaces.

What a package is

A package is just a workspace folder that has been tagged with the Docly Package schema. The folder's contents — schemas, templates, code, libs, services, content — are what gets copied into a target workspace when the package is installed.

There is no separate manifest file. The package metadata lives in the folder's properties (its .docly file), and the rest of the folder is the payload.

Step 1: Create a package workspace

  1. Create a new workspace for your package — keep packages separate from your application workspaces so the contents stay clean

  2. Install the Developer Tools package so you can edit schemas and code

  3. Open the workspace folder properties and switch its schema to Docly Package

The folder now exposes the package metadata fields described below.

Step 2: Fill in the metadata

  • Title — display name shown in package lists

  • Version — semantic version x.y.z. Required and validated when releasing.

  • Description — one-line summary of what the package provides

  • Homepage — optional URL for documentation or marketing site

  • License — optional

  • Dependencies — other packages that must be installed for this one to work

  • Developers — flag the package as developer-only (hidden from non-developer package lists). Use for tooling like Docly Package Releaser.

Step 3: Add content

Anything you put in the package folder becomes part of the package. Use the standard Docly conventions:

  • Schemas/ — schema definitions (Documents & Schemas)

  • #/ — server-side code, APIs and templates (API & Services, Templates & Rendering)

  • Libs/ — shared JavaScript libraries imported by your code

  • Services/ — scheduled tasks and event handlers

  • Root/ — static assets exposed under /

  • Top-level .hash files — display templates and master pages

When the package is installed, all of this is copied into the target workspace at the same paths. Design your code with that in mind — avoid hard-coded workspace-specific assumptions.

Step 4: Test it locally

Before releasing, verify the package works in a clean target workspace:

  1. Create an empty test workspace

  2. Install your package

  3. Verify schemas, templates and code resolve as expected — pay attention to anything referencing absolute paths

Next: publish it

Once your package works end to end, publish a release so it can be installed elsewhere. See Publishing a package.