Domo Publish Action

What is it?

The Domo Publish Action is a GitHub Action that automatically deploys your Domo applications directly from your GitHub repository to your Domo instance. No manual steps, no command-line hassles — just push your code and let CI/CD handle the rest.

Why you want to use it

If you’re manually running domo publish every time you make changes, you’re wasting valuable development time. The Domo Publish Action eliminates repetitive deployment tasks by:

Automating the entire publish workflow when code is merged
Controlling access to production deployments without giving every developer publish permissions. Use a dedicated CI/CD service account with properly scoped grants, so only approved code that passes your review process gets deployed
Securing your credentials with GitHub Secrets instead of local tokens
Supporting multiple environments (dev, staging, production)
Providing instant feedback with detailed deployment status in your PR checks

How it accelerates development

Traditional workflow:

Make code changes
Commit and push
Manually run domo login
Run domo publish
Wait and monitor
Repeat for each environment

With Domo Publish Action:

Make code changes
Push to GitHub
Everything else happens automatically

Quick setup

Get your Domo credentials: Admin → Authentication → Personal Access Tokens
Add to GitHub Secrets: Store the token as DOMO_ACCESS_TOKEN in your repository
Create workflow file: Add to .github/workflows/deploy.yml
Push and relax: Your app deploys automatically on merge

name: Deploy to Domo
on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-node@v4
        with:
          node-version: '24'
          cache: 'npm'

      - name: Deploy to Domo
        uses: DomoApps/domoapps-publish-action@v3.0.0
        with:
          domo-token: ${{ secrets.DOMO_ACCESS_TOKEN }}
          domo-instance: https://your-company.domo.com
          build-command: npm run build
          publish-dir: ./build

The result? More time building features, less time managing deployments, credentials, and permissions. Your Domo apps deploy consistently, securely, and automatically with every merge.

Inputs

Input	Required	Default	Description
`domo-token`	✅	—	Domo API token for authentication. Store as a GitHub secret.
`domo-instance`	✅	—	Domo instance URL, e.g. `https://your-company.domo.com`.
`working-directory`	❌	`.`	Source directory. Where dependencies install and `build-command` runs.
`build-command`	❌	—	Optional shell command, run inside `working-directory`. Chain multiple steps with `&&`.
`publish-dir`	❌	(matches `working-directory`)	Built artifact to upload. Resolved relative to `working-directory`. Set to your build output folder.

Outputs

Output	Description
`deployment-status`	`success` or `failed`
`app-url`	URL of the deployed app on the Domo instance

Usage examples

React / Vite app (recommended pattern)

Source at the repo root, Vite emits to ./build:

- uses: DomoApps/domoapps-publish-action@v3.0.0
  with:
    domo-token: ${{ secrets.DOMO_ACCESS_TOKEN }}
    domo-instance: https://your-company.domo.com
    build-command: npm run build
    publish-dir: ./build

Source in a subfolder (./app):

- uses: DomoApps/domoapps-publish-action@v3.0.0
  with:
    domo-token: ${{ secrets.DOMO_ACCESS_TOKEN }}
    domo-instance: https://your-company.domo.com
    working-directory: ./app
    build-command: npm run build
    publish-dir: ./dist

publish-dir is resolved relative to working-directory, so ./dist above means ./app/dist.

Create React App (CRA)

- uses: DomoApps/domoapps-publish-action@v3.0.0
  with:
    domo-token: ${{ secrets.DOMO_ACCESS_TOKEN }}
    domo-instance: https://your-company.domo.com
    build-command: npm run build
    publish-dir: ./build

CRA + da apply-manifest — if your CRA template uses da apply-manifest in its build (prestart / prebuild / build:dev etc.), add @domoinc/da to your devDependencies. The CLI is typically installed globally on developer machines, so locally it works; in CI’s clean install it isn’t on PATH and the build fails with sh: 1: da: not found. Pinning it as a devDependency puts the binary in node_modules/.bin where npm scripts can find it.
// package.json
{
  "devDependencies": {
    "@domoinc/da": "^2.3.0"
  }
}

ProCode / flat app (no build)

When manifest.json, index.html, etc. live at the repo root and there’s no build step:

- uses: DomoApps/domoapps-publish-action@v3.0.0
  with:
    domo-token: ${{ secrets.DOMO_ACCESS_TOKEN }}
    domo-instance: https://your-company.domo.com

Defaults handle this — working-directory: . and publish-dir falls back to working-directory.

With pre-build checks (lint, test, type-check)

build-command is a shell string — chain with && to gate the publish on quality checks:

- uses: DomoApps/domoapps-publish-action@v3.0.0
  with:
    domo-token: ${{ secrets.DOMO_ACCESS_TOKEN }}
    domo-instance: https://your-company.domo.com
    build-command: npm run lint && npm test -- --watchAll=false && npm run build
    publish-dir: ./build

Or split into a dedicated checks step before this one — failures block the deploy:

- run: npm ci   # only needed because the steps below run before the action's auto-install

- name: Lint & test
  run: |
    npm run lint
    npm test -- --watchAll=false

- name: Build & deploy
  uses: DomoApps/domoapps-publish-action@v3.0.0
  with:
    domo-token: ${{ secrets.DOMO_ACCESS_TOKEN }}
    domo-instance: https://your-company.domo.com
    build-command: npm run build
    publish-dir: ./build

With per-environment manifest overrides

Domo Apps templates ship with da apply-manifest (from the @domoinc/da CLI) to swap dataset IDs / app IDs per environment. Add @domoinc/da to your devDependencies so it’s available in CI, then chain it into your build:

// package.json
{
  "scripts": {
    "build:prod": "da apply-manifest production && vite build"
  },
  "devDependencies": {
    "@domoinc/da": "^2.3.0"
  }
}

- uses: DomoApps/domoapps-publish-action@v3.0.0
  with:
    domo-token: ${{ secrets.DOMO_ACCESS_TOKEN }}
    domo-instance: https://your-company.domo.com
    build-command: npm run build:prod
    publish-dir: ./build

Multi-environment deploys (dev / qa / prod)

A single workflow keyed off the branch:

name: Deploy to Domo
on:
  push:
    branches: [main, qa, develop]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '24'
          cache: 'npm'

      - name: Resolve environment
        id: env
        run: |
          case "${{ github.ref_name }}" in
            main)    echo "name=prod" >> $GITHUB_OUTPUT
                     echo "instance=https://prod.domo.com" >> $GITHUB_OUTPUT ;;
            qa)      echo "name=qa"   >> $GITHUB_OUTPUT
                     echo "instance=https://qa.domo.com"   >> $GITHUB_OUTPUT ;;
            develop) echo "name=dev"  >> $GITHUB_OUTPUT
                     echo "instance=https://dev.domo.com"  >> $GITHUB_OUTPUT ;;
          esac

      - uses: DomoApps/domoapps-publish-action@v3.0.0
        with:
          domo-token: ${{ secrets[format('DOMO_TOKEN_{0}', steps.env.outputs.name)] }}
          domo-instance: ${{ steps.env.outputs.instance }}
          build-command: npm run build:${{ steps.env.outputs.name }}
          publish-dir: ./build

Stash three secrets (DOMO_TOKEN_DEV, DOMO_TOKEN_QA, DOMO_TOKEN_PROD) and three build scripts (build:dev, build:qa, build:prod).

Deploy only when app code changes

Skip a deploy when only docs or workflows change:

on:
  push:
    branches: [main]
    paths:
      - 'src/**'
      - 'public/**'
      - 'package.json'
      - 'package-lock.json'
      - '.github/workflows/deploy.yml'

Using outputs (status checks, notifications)

- name: Deploy
  id: deploy
  uses: DomoApps/domoapps-publish-action@v3.0.0
  with:
    domo-token: ${{ secrets.DOMO_ACCESS_TOKEN }}
    domo-instance: https://your-company.domo.com
    build-command: npm run build
    publish-dir: ./build

- name: Slack on failure
  if: failure() && steps.deploy.outputs.deployment-status == 'failed'
  run: |
    curl -X POST ${{ secrets.SLACK_WEBHOOK }} \
      -H 'Content-Type: application/json' \
      -d "{\"text\":\"❌ Deploy failed for ${{ github.repository }} @ ${{ github.sha }}\"}"

- name: Comment on PR
  if: github.event_name == 'pull_request' && steps.deploy.outputs.app-url
  uses: actions/github-script@v7
  with:
    script: |
      github.rest.issues.createComment({
        issue_number: context.issue.number,
        owner: context.repo.owner,
        repo: context.repo.repo,
        body: `Deployed to ${{ steps.deploy.outputs.app-url }}`
      })

pnpm and yarn

The action auto-detects your package manager from the lockfile and runs the install for you. For pnpm you still need to make the pnpm binary available on the runner:

# pnpm
- uses: actions/checkout@v4
- uses: pnpm/action-setup@v4
  with: { version: 9 }
- uses: actions/setup-node@v4
  with: { node-version: '24', cache: 'pnpm' }
- uses: DomoApps/domoapps-publish-action@v3.0.0
  with:
    domo-token: ${{ secrets.DOMO_ACCESS_TOKEN }}
    domo-instance: https://your-company.domo.com
    build-command: pnpm build
    publish-dir: ./build

# yarn
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
  with: { node-version: '24', cache: 'yarn' }
- uses: DomoApps/domoapps-publish-action@v3.0.0
  with:
    domo-token: ${{ secrets.DOMO_ACCESS_TOKEN }}
    domo-instance: https://your-company.domo.com
    build-command: yarn build
    publish-dir: ./build

You don’t need a separate npm install / yarn install / pnpm install step — the action does it for you using whichever package manager matches your lockfile. Add your own install step only if you have pre-build commands (lint, test, type-check) running in earlier steps that need node_modules.

Migrating from v2

v3 reframes working-directory to mean the source directory. The new publish-dir input names the build output. In v2, the action used working-directory for both — which meant if you set it to ./build, your build command tried to run from there (no package.json). If you left it at ., the publish step uploaded the entire repo (including docs/, node_modules/, etc.).

- uses: DomoApps/domoapps-publish-action@v2
+ uses: DomoApps/domoapps-publish-action@v3.0.0
  with:
    domo-token: ${{ secrets.DOMO_ACCESS_TOKEN }}
    domo-instance: https://your-company.domo.com
    build-command: npm run build
-   working-directory: ./build
+   publish-dir: ./build

If you don’t run a build (flat ProCode app), no change is needed — defaults still publish from the repo root.

Also fixed in v3

Each deploy no longer creates a new design. v2 invoked domo publish --build-dir <dir>, which made ryuu read the manifest from the caller’s CWD (your repo root, where public/manifest.json typically has no id). Result: a brand-new app on every run, even though your build output had the right id. v3 chdirs into publish-dir first and runs plain domo publish, so ryuu reads the manifest your build actually emitted. Tools like da apply-manifest that write the resolved id into the build output Just Work now.
./build/build resolution bug (the v2 working-directory + --build-dir interaction) is gone.

Troubleshooting

Symptom	Likely cause	Fix
`Manifest not found`	`publish-dir` doesn’t contain `manifest.json` after build	Ensure your build copies `manifest.json` into the publish output (e.g. via Vite’s `public/` folder). Verify locally: `ls $(your-build-dir)/manifest.json`
`Authentication failed`	Bad / expired token, or wrong instance URL	Regenerate the token in Domo admin. Ensure `domo-instance` includes the `https://` scheme.
Each deploy creates a new app	`manifest.json` inside `publish-dir` has no `id`, or its `id` doesn’t exist on the target instance	After the first publish, ensure the `id` from `<publish-dir>/manifest.json` is what subsequent runs publish. If you use `da apply-manifest` for per-env overrides, confirm `manifestOverrides.json` has the right `id` for that env. v3 reads the manifest from the build output, so anything written there at build time is what ryuu sees.
Repo files leak into the published app	Using v2 without an isolated `working-directory`, or upgraded to v3 but didn’t set `publish-dir`	Set `publish-dir` to your build output folder.
`sh: 1: da: not found` (or other CLI not on PATH in CI)	The CLI is installed globally locally but not in CI’s clean install	Add the CLI as a `devDependency` (e.g. `@domoinc/da`) so `npm ci` puts it in `node_modules/.bin`.
AppDB calls fail at runtime	Missing `proxyId` in `manifest.json`	After first publish with `collections`, copy `proxyId` from `build/manifest.json`.

Debug logs

Enable verbose logs by setting these as GitHub Actions secrets on your repo:

ACTIONS_STEP_DEBUG = true
ACTIONS_RUNNER_DEBUG = true

Using with other CI/CD platforms

The Domo Publish Action uses the Domo CLI (ryuu npm package) under the hood, which means the same pattern works with any CI/CD platform that supports Node.js. Whether you’re using GitLab CI, Jenkins, CircleCI, Azure DevOps, or any other platform, you can adapt this workflow: Core pattern:

# Install the CLI
npm install -g ryuu

# Authenticate
domo login -i your-instance.domo.com -t $DOMO_ACCESS_TOKEN

# Run lint, test, build, etc.
npm run build

# Publish from inside the build output (NOT `domo publish --build-dir ./build`)
cd build && domo publish

Why cd instead of --build-dir: ryuu reads manifest.json before applying its own --build-dir chdir, so it would resolve the manifest against the caller’s CWD (often public/manifest.json with no id) — causing a brand-new design to be created on every run. Chdir-ing yourself first lets ryuu’s manifest lookup land directly on the resolved file your build emitted.

Example for GitLab CI:

deploy:
  image: node:24
  script:
    - npm ci
    - npm install -g ryuu
    - domo login -i your-instance.domo.com -t $DOMO_ACCESS_TOKEN
    - npm run build
    - cd build && domo publish
  only:
    - main

The same three-step pattern (install → authenticate → publish) works universally across any CI/CD platform with Node.js support.

Getting Started

API Reference

Build Apps

Automate Actions

Partner Developers

AI Resources Guide

Connect Data

Embed Domo Everywhere

Govern Your Domo Instance

Other Resources

Developer Topics

Domo SDK

Domo Publish Action

What is it?

Why you want to use it

How it accelerates development

Quick setup

Inputs

Outputs

Usage examples

React / Vite app (recommended pattern)

Create React App (CRA)

ProCode / flat app (no build)

With pre-build checks (lint, test, type-check)

With per-environment manifest overrides

Multi-environment deploys (dev / qa / prod)

Deploy only when app code changes

Using outputs (status checks, notifications)

pnpm and yarn

Migrating from v2

Also fixed in v3

Troubleshooting

Debug logs

Using with other CI/CD platforms

Getting Started

API Reference

Build Apps

Automate Actions

Partner Developers

AI Resources Guide

Connect Data

Embed Domo Everywhere

Govern Your Domo Instance

Other Resources

Developer Topics

Domo SDK

Documentation Index

​What is it?

​Why you want to use it

​How it accelerates development

​Quick setup

​Inputs

​Outputs

​Usage examples

​React / Vite app (recommended pattern)

​Create React App (CRA)

​ProCode / flat app (no build)

​With pre-build checks (lint, test, type-check)

​With per-environment manifest overrides

​Multi-environment deploys (dev / qa / prod)

​Deploy only when app code changes

​Using outputs (status checks, notifications)

​pnpm and yarn

​Migrating from v2

​Also fixed in v3

​Troubleshooting

​Debug logs

​Using with other CI/CD platforms

What is it?

Why you want to use it

How it accelerates development

Quick setup

Inputs

Outputs

Usage examples

React / Vite app (recommended pattern)

Create React App (CRA)

ProCode / flat app (no build)

With pre-build checks (lint, test, type-check)

With per-environment manifest overrides

Multi-environment deploys (dev / qa / prod)

Deploy only when app code changes

Using outputs (status checks, notifications)

pnpm and yarn

Migrating from v2

Also fixed in v3

Troubleshooting

Debug logs

Using with other CI/CD platforms