Your ServiceNow
code, in Git.

Studio source control locks your code inside the instance. SyncroNow inverts that: the source you write lives in Git, and its build output is what lands in ServiceNow. The code you author is never the code that runs.

+ class Example {+   sayHello() {+     gs.info("Hi, SyncroNow!");+   }+ }

"use strict";
var Example = (function () {
  function Example() {}
  _createClass(Example, [{
    key: "sayHello", value: …
  }]);
  return Example;
})();

For teams deciding how to manage ServiceNow scoped-app code. SyncroNow AI is pre-1.0 and early — these are the honest trade-offs.

Honest gaps today: versus first-party tooling it still lacks SSO in the MCP server, a support SLA, and a packaged distribution (Homebrew / Windows installer). These are the active priorities — see the roadmap.

You need Node.js 22+ and a ServiceNow instance you can reach — a free PDI works great. WSL is required on Windows.

npm i -g syncrona
# or as a project dev dependency:
npm i -D syncrona

syncrona login
syncrona init

npx syncrona dev

git clone https://github.com/IvanBBaev/syncrona
cd syncrona
npm ci
npm run build

npm link --workspace syncrona
syncrona login
syncrona init

npx syncrona dev

Source code is owned locally; everything else — tables, dictionary, config records, metadata — stays managed in ServiceNow and moves with your usual update-set / deploy process.

project/
  src/
    table_name/
      record_name/
        field_name.ext

Every command runs as npx syncrona <cmd> (or bare syncrona if installed globally). Filter below.

A single sync.config.js in your project root drives everything — source layout, plugin rules, and which tables/fields are tracked.

module.exports = {
  sourceDirectory: "src",   // watched in dev mode
  buildDirectory: "build",  // where local builds are written
  // Most specific extension first — the first matching rule wins.
  rules: [
    { match: /\.ts$/, plugins: [
      { name: "@syncrona/typescript-plugin" },
      { name: "@syncrona/babel-plugin" },
    ] },
  ],
  excludes: {},  // tables/fields to drop, on top of defaults
  includes: {},  // tables/fields to force-track
  refreshInterval: 30,
};

excludes: {
  sys_scope_privilege: false, // re-enable a default
  my_cool_table: true,        // drop a whole table
  new_table: { cool_script: true },
},
includes: {
  sys_report: true,           // force-track
  special_table: { field: { type: "js" } },
}

rules: [
  { match: /\.secret\.ts$/, plugins: [] }, // no-op
  { match: /\.ts$/, plugins: [
    { name: "@syncrona/typescript-plugin",
      options: { transpile: false } },
  ] },
]

tableOptions: {
  some_table: {
    displayField: "name",
    differentiatorField: ["version", "sys_id"],
    query: "active=true",
  },
}

Each is a separate @syncrona/* dev dependency wired into a rule. Chains run in order — the output of one feeds the next.

The bundled Model Context Protocol server (@syncrona/mcp-server) turns any MCP-capable client — Claude Desktop, Claude Code, VS Code Chat — into a teammate that can read your scope, map dependencies, analyse scripts and propose gated changes behind a dry-run guardrail. It exposes 61 MCP tools in 8 families.

Run npx syncrona mcp to start the server and optionally write local client config (.vscode/mcp.json, .syncrona-mcp/secrets.json), or register it directly:

{
  "mcpServers": {
    "syncrona": {
      "command": "npx",
      "args": ["-y", "@syncrona/mcp-server"]
    }
  }
}

Authenticate with a dedicated least-privilege integration user over HTTPS — never your admin account. Six authentication options: HTTP Basic, three OAuth 2.0 grants, an inbound REST API key, and mutual TLS layered on top of any of them.

Authentication methods

syncrona login shows a method picker, or pass --auth-method non-interactively. Everything can also come from env vars — SN_AUTH_METHOD selects the method; Basic needs none, so a legacy .env keeps working unchanged.

OAuth grants exchange credentials for a Bearer token at oauth_token.do, refreshing on expiry or 401. The JWT signing key and mTLS cert/key are stored by path only — key material never enters the encrypted store.

Where credentials live

The global store writes each instance to ~/.syncrona/credentials/<instance>.enc, encrypted with AES-256-GCM. The encryption key is resolved with this precedence:

Safety model

• Least-privilege by default. A dedicated integration user with only the roles your scope needs.
• Encrypted credential store. AES-256-GCM at rest; set a real key or enable the keychain for genuine at-rest protection.
• Dry-run everything risky. --dry-run previews push, deploy, download and build; the MCP server gates writes behind confirmation and dry-run.
• Destructive ops confirm first. download and repair ask before overwriting (--ci skips the prompt) — keep source in Git so a bad run is a git checkout away.
• Secrets stay out of Git. Ignore .env and node_modules; for CI, source SYNCRONA_STORE_KEY from a secrets manager.
• One secret detector, fail-closed. @syncrona/redaction is the single answer to “is this a credential?” — key names, secret-shaped values, a bounded scan budget that reports rather than skips oversized input, and a redaction marker digested from the plaintext so a rotated secret still shows a diff.

A Node 22 monorepo of 14 @syncrona/* packages. Two ServiceNow clients — the core CLI and the MCP server — share one transport policy, one encrypted credential store and one secret detector, so auth, scoped-API resolution, retry behaviour and redaction are identical across both.

CLI commands and MCP tool families are each declared one entry at a time in a registry; the orchestrators are generic interpreters, so adding a command or tool family is a contained, contract-checked change. Quality gates (type-check, lint, dependency-cruiser module boundaries, tests) run via npm run check. Full detail: docs/ARCHITECTURE.md.