# Setting up a NetSuite SuiteCloud CI/CD pipeline > Source: https://netray.co/erp-help/netsuite-suitecloud-ide-cicd-pipeline-setup > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: ERP Help ## Short answer A repeatable NetSuite CI/CD pipeline uses SuiteCloud CLI for Node.js authenticated non-interactively with a Token-Based Authentication saved authentication ID, running suitecloud project:validate then project:deploy against a target account from a pipeline runner rather than a developer's machine. The main setup work is generating CI-specific TBA credentials, storing them as pipeline secrets, and keeping manifest.xml/deploy.xml accurate so deploys are deterministic. ## Kind advanced ## System netsuite ## Erp Oracle NetSuite ## Module SuiteCloud Development Framework (SDF) / CI/CD ## Query how to set up netsuite suitecloud cli in a ci/cd pipeline ## Alternate Queries - suitecloud cli github actions netsuite deploy - netsuite sdf ci cd automated deployment - suitecloud cli saved authentication ci - netsuite vscode extension sdf project setup ## Applies To SuiteCloud CLI for Node.js, SuiteCloud Development Framework (SDF) projects, any CI runner (GitHub Actions, GitLab CI, Jenkins, Azure DevOps) ## Steps ### Wire SuiteCloud CLI into a CI/CD pipeline **Items:** Install @oracle/suitecloud-cli as a project dependency (not just globally) so the pipeline uses a pinned, reproducible version rather than whatever is on the runner by default. Create a dedicated Integration record and a Token-Based Authentication access token specifically for CI use, tied to a role scoped to only what deployment requires (SuiteCloud Development Framework permission, plus record permissions for whatever the project touches), separate from any individual developer's token. On a machine you control (not the CI runner itself, to avoid interactive prompts in CI), run suitecloud account:setup to save the CI credentials under a named authentication ID, or use account:setup -i for a scriptable, non-interactive flow with the token values passed as parameters. Store the resulting authentication ID and underlying TBA values (or the account:savetoken output, depending on CLI version) as encrypted secrets in the CI platform, never committed to source control. In the pipeline definition, add a stage that runs suitecloud project:validate --server against the target account first; treat validation failures as a hard gate that blocks deploy. Add a subsequent stage that runs suitecloud project:deploy --accountspecificvalues WARNING (or ERROR, depending on how strict you want account-specific value handling) only after validate passes and, for production, only on a protected branch or after manual approval. Keep manifest.xml's dependencies section accurate (required features, other SuiteApp dependencies) since a mismatch between what the project declares and what the target account has enabled fails validation with a dependency error rather than a vague one. Version deploy.xml carefully in source control; treat it as part of code review, since it silently determines what does and does not ship on every pipeline run. ## Sections ### Why non-interactive authentication is the main blocker **Body:** SuiteCloud CLI's default account:setup flow is interactive (browser-based OAuth-style login), which does not work unattended on a CI runner. The practical fix is authenticating once, interactively, on a developer or admin machine using CI-specific TBA credentials, and then reusing the resulting saved authentication ID (or the raw token values, depending on CLI version and pipeline design) as a secret the pipeline injects at run time. Using a personal developer's saved authentication in CI is a common shortcut that causes two problems: it ties the pipeline's ability to deploy to one person's account access (breaking if they leave or their token is revoked), and it makes deploy audit logs attribute every CI deployment to that individual rather than to an identifiable CI identity. ### Validate-then-deploy as a real gate **Body:** project:validate --server runs the same checks the account would apply on deploy (missing dependencies, invalid references, permission issues) without actually writing anything, which makes it a safe, repeatable CI step to run on every pull request, not just before a deploy to production. Treating validate failures as a blocking CI check (rather than only running it manually before deploy) catches broken references and missing custom fields at pull request time, well before anyone attempts an actual deploy to a shared sandbox or production. **Code:** # example CI steps (pseudocode, adapt to your platform) npm ci npx suitecloud project:validate --server --authid $CI_NETSUITE_AUTH_ID # gate: fail pipeline if validate returns non-zero npx suitecloud project:deploy --server --authid $CI_NETSUITE_AUTH_ID --accountspecificvalues WARNING ### Handling account-specific values and multiple targets **Body:** Some object references (a specific subsidiary internal ID, a role ID) differ between sandbox and production, which SDF flags as account-specific values during deploy. Setting --accountspecificvalues WARNING lets the deploy proceed with a logged warning for manual review, while ERROR blocks the deploy outright; pick based on how strictly the team wants to catch environment drift. For pipelines that deploy the same SDF project to multiple accounts (a sandbox for QA, then production), maintain a separate saved authentication ID per target account and a pipeline stage per environment, rather than trying to parameterize a single authentication for multiple accounts, since SDF's project structure assumes one account context per deploy. ## Pitfalls - Reusing a developer's personal saved authentication for CI deploys instead of a dedicated CI Integration record and token. - Running project:deploy directly without a preceding project:validate gate, letting broken references reach a shared account. - Committing TBA consumer keys, tokens or account IDs directly into pipeline configuration files instead of using the CI platform's secret storage. - Letting deploy.xml drift out of sync with the actual Objects/ and FileCabinet/ directories so the pipeline silently omits new customizations from a deploy. - Deploying straight to production from every merge to a shared branch without a manual approval gate or a sandbox-first stage. ## Ai Angle SyteRay-style grounded review of an SDF project ahead of a CI run can flag manifest.xml dependency mismatches, deploy.xml entries pointing at objects that no longer exist, and account-specific value references likely to trigger a WARNING or ERROR, catching what would otherwise surface only mid-pipeline. For teams standing up their first NetSuite CI/CD pipeline, that grounded pre-check often shortens the initial setup by several failed-deploy iterations. ## Faq ### Can SuiteCloud CLI authenticate with OAuth 2.0 instead of TBA in a pipeline? **Answer:** Recent SuiteCloud CLI versions support machine-to-machine OAuth 2.0 for non-interactive authentication in addition to TBA; either works for CI as long as the credentials are CI-specific and stored as pipeline secrets rather than reused from an individual's account. ### Does project:validate catch every error that project:deploy would? **Answer:** It catches most structural issues (missing dependencies, invalid object references, permission problems) but a few runtime-only failures can still surface during an actual deploy. Treat validate as a strong first gate, not an absolute guarantee that deploy will succeed. ### Should sandbox and production use the same SDF project and deploy.xml? **Answer:** Yes, the same SDF project should deploy to both, with the CI pipeline pointing at a different saved authentication ID per environment; maintaining separate project copies per environment defeats the point of a single source of truth and invites drift. ### What is the risk of setting --accountspecificvalues WARNING instead of ERROR everywhere? **Answer:** WARNING lets a deploy with an environment-specific reference mismatch (like a subsidiary ID valid in one account but not another) proceed anyway, which is convenient but can silently deploy a broken reference to production if nobody reviews the warning output; ERROR is safer for production pipelines at the cost of requiring more manual reconciliation. ## Search terms suitecloud cli ci/cd pipeline, netsuite sdf automated deployment, suitecloud cli non interactive authentication, netsuite project:validate project:deploy, netsuite ci cd token based authentication, suitecloud cli github actions, netsuite deploy.xml manifest.xml pipeline, netsuite accountspecificvalues warning error --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json