Overview
Once your app is built and tested locally, you have two paths for distributing it:- Deploy a tarball — upload your app directly to a specific Twenty server for internal or private use.
- Publish to npm — list your app in the Twenty marketplace for any workspace to discover and install.
Building your app
Run the build command to compile your app and generate a distribution-readymanifest.json:
.twenty/output/. Add --tarball to also produce a .tgz package for manual distribution or the publish command.
Deploying to a server (tarball)
For apps you don’t want publicly available — proprietary tools, enterprise-only integrations, or experimental builds — you can deploy a tarball directly to a Twenty server.Prerequisites
Before deploying, you need a configured remote pointing to the target server. Remotes store the server URL and authentication credentials locally in~/.twenty/config.json.
Add a remote:
Deploying
Build and upload your app to the server in one step:Sharing a deployed app
Tarball apps are not listed in the public marketplace, so other workspaces on the same server won’t discover them by browsing. Once your workspace is on the Enterprise plan, you can share a deployed app like this:- Go to Settings > Applications > Registrations and open your app
- In the Distribution tab, click Copy share link
- Share this link with users on other workspaces — it takes them directly to the app’s install page
Version management
When updating an already deployed tarball app, the server requires theversion in package.json to be strictly higher (per semver ordering) than the currently deployed version. Re-deploying the same version, or pushing a lower one, is rejected before the tarball is stored — you’ll see a VERSION_ALREADY_EXISTS error from the CLI.
To release an update:
- Bump the
versionfield in yourpackage.json(e.g.1.2.3→1.2.4,1.3.0, or2.0.0) - Run
yarn twenty app:publish --private(oryarn twenty app:publish --private --remote production) - Workspaces that have the app installed and enabled auto-upgrade for it (in the app’s Settings tab) are upgraded automatically in the background; the others will see the upgrade available in their settings
Pre-release tags work as expected: bumping
1.0.0-rc.1 → 1.0.0-rc.2 is allowed, and a final release like 1.0.0 is correctly recognized as higher than 1.0.0-rc.5. The version in package.json must itself be a valid semver string.Server version compatibility
If your app uses a feature introduced in a specific Twenty server version (for example, OAuth providers added in v2.3.0), you should declare the minimum server version your app requires using theengines.twenty field in package.json:
What happens at deploy and install time:
- If
engines.twentyis set and the target server’s version does not satisfy the range, the deploy (tarball upload) or install is rejected with aSERVER_VERSION_INCOMPATIBLEerror and a message indicating both the required range and the actual server version. - If
engines.twentyis not set, the app is accepted on any server version (backward-compatible with existing apps). - If the server has no
APP_VERSIONconfigured, the check is skipped.
The server is the authoritative check — it validates
engines.twenty on both tarball upload and workspace install. If you deploy a tarball out-of-band or install from the marketplace, the server still enforces compatibility.Automated CI/CD (scaffolded workflows)
Apps generated withcreate-twenty-app ship with three GitHub Actions workflows out of the box, under .github/workflows/. CI runs with no setup, CD requires a single secret, and publishing to npm requires a one-time npm trusted-publisher setup.
CI — ci.yml
Runs integration tests on every push to main and every pull request.
What it does:
- Checks out your app’s source.
- Spawns an isolated Twenty test instance using the
twentyhq/twenty/.github/actions/spawn-twenty-app-dev-test@maincomposite action (the CI equivalent ofyarn twenty docker:start --test). - Enables Corepack, sets up Node.js from your
.nvmrc, and installs dependencies withyarn install --immutable. - Runs
yarn test, passingTWENTY_API_URLandTWENTY_API_KEYfrom the spawned instance so your tests can talk to a real server.
TWENTY_VERSION(env, defaults tolatest) — pin the Twenty server version used in CI by editing this inci.yml.- Concurrency is grouped by
github.refand cancels in-progress runs on new pushes.
CD — cd.yml
Deploys your app to a configured Twenty server on every push to main, and optionally from a pull request when the deploy label is applied.
What it does:
- Checks out the PR head (for labeled PRs) or the pushed commit.
- Runs
twentyhq/twenty/.github/actions/deploy-twenty-app@main— the CI equivalent ofyarn twenty app:publish --private. - Runs
twentyhq/twenty/.github/actions/install-twenty-app@mainso the newly deployed version is installed into the target workspace.
The default
TWENTY_DEPLOY_URL of http://localhost:3000 is a placeholder — it will not reach anything from a GitHub-hosted runner. Update it to your server’s public URL (or use a self-hosted runner with network access) before enabling CD.deploy label to a pull request. The if: guard in cd.yml will run the job for that PR using the PR’s head commit, letting you validate a change on the target server before merging.
Publish — publish.yml
Publishes your app to npm with provenance when you push a version tag (e.g. v1.0.0), or when you run the workflow manually from the Actions tab.
What it does:
- Checks out your app, sets up Node.js, and updates npm (trusted publishing requires npm 11.5.1 or later).
- Runs
yarn twenty app:publish, which builds the app and publishes.twenty/outputto npm. In CI it automatically adds--provenanceand--access public, so no flags are needed in the workflow.
publish.yml workflow (see the npm trusted publishing docs). Publishing with provenance certifies which GitHub repository built the package, which is also how you claim ownership of your app in a Twenty marketplace.
npm only accepts provenance from public source repositories. If you publish from a private repo, npm rejects the OIDC provenance bundle with an
E422 ... Unsupported GitHub Actions source repository visibility: "private" error. To publish from a private repo, opt out of provenance by setting TWENTY_APP_PUBLISH_DISABLE_PROVENANCE: 'true' in the publish step’s env (a commented-out hint is included in the scaffolded publish.yml):Pinning the reusable actions
Theci.yml and cd.yml workflows reference reusable actions at @main, so action updates in the twentyhq/twenty repo are picked up automatically. If you want deterministic builds, replace @main with a commit SHA or release tag on each uses: line.
Publishing to npm
Publishing to npm makes your app discoverable in the Twenty marketplace. Any Twenty workspace can browse, install, and upgrade marketplace apps directly from the UI.Requirements
- An npm account
- The
twenty-appkeyword in yourpackage.jsonkeywordsarray (add it manually — it is not included by default in thecreate-twenty-apptemplate)
Marketplace metadata
ThedefineApplication() config supports optional fields that control how your app appears in the marketplace. Use logo and galleryImages to reference images from the public/ folder:
src/application-config.ts
author, category, aboutDescription, websiteUrl, termsUrl, etc.).
Recommended gallery image dimensions
The marketplace rendersgalleryImages in a fixed 8:5 container (for example, 1600×1000 px).
Gallery images of any aspect ratio are displayed in full and are never cropped, but anything significantly taller or narrower than
8:5 will show empty bands on the sides.Image size limit
Thelogo and each galleryImages file must not exceed 10 MB. Larger files are skipped when the marketplace rehosts your published assets, so they will not be displayed.
Publish
beta or next):
How marketplace discovery works
The Twenty server syncs its marketplace catalog from the npm registry every hour. You can trigger the sync immediately instead of waiting:defineApplication() config — see Marketplace metadata above.
If your app does not define an
aboutDescription in defineApplication(), the marketplace will automatically use your package’s README.md from npm as the about page content. This means you can maintain a single README for both npm and the Twenty marketplace. If you want a different description in the marketplace, explicitly set aboutDescription.CI publishing
The scaffoldedpublish.yml workflow described above publishes to npm automatically on version tags, with provenance. Because yarn twenty app:publish adds --provenance and --access public for you when it runs in CI, the workflow needs no npm flags — only the one-time trusted-publisher setup.
For other CI systems (GitLab CI, CircleCI, etc.), run yarn install then yarn twenty app:publish. Provenance is emitted when the environment can mint an OIDC token and skipped automatically otherwise.
npm provenance adds a trust badge to your npm listing, letting users verify the package was built from a specific commit in a public CI pipeline. It is also what lets you claim ownership of your app in a Twenty marketplace. See the npm provenance docs for details.
Installing apps
Once an app is published (npm) or deployed (tarball), workspaces can install it through the UI. Go to the Settings > Applications page in Twenty, where both marketplace and tarball-deployed apps can be browsed and installed. You can also install apps from the command line:The server enforces semver versioning on install, mirroring the rules on deploy:
- Installing the same version that is already installed in your workspace is rejected with an
APP_ALREADY_INSTALLEDerror. - Installing a lower version than the one currently installed is rejected with a
CANNOT_DOWNGRADE_APPLICATIONerror.
yarn twenty app:install.