Zinnector® ਨਾਲ ਡਿਪਲਾਇਡ ਕਰ ਰਿਹਾ ਹੈ: ਲਿੰਕ, ਚੈੱਕ, ਪੁਸ਼

Once a project runs locally, four commands take it to a live site on Zinn Digital® hosting: sign in, link the project to a hosting slot, read the pre-flight, and push. This article walks through each one, what it prints, and the commands you reach for afterwards — redeploys, deploy history and build logs.

Sign in with an API key

Create a key in the dashboard under Settings → API keys, then:

zinnector login

The key is typed at a prompt — it is never accepted on the command line, so it cannot end up in your shell history or a process listing. In CI, pipe it in: echo "$ZINN_API_KEY" | zinnector login --profile ci, or set ZINNECTOR_TOKEN and skip login entirely. The key is verified before it is stored, and stored with file mode 600. zinnector whoami --scopes shows which organisation you are signed in to and which permissions the key carries; a sandbox key is labelled as one.

Link the project to a slot

zinnector link                                   # pick a site from a list
zinnector link example.com --repo acme/site --branch main

link writes the site's id into zinnector.json and, unless you pass --no-repo, connects the project's git remote to the site on the platform so that a push deploys it. Commit zinnector.json: a colleague who clones the repository then deploys to the same place without being told. It holds no secret.

Read the pre-flight

zinnector check

This is the command the CLI exists for. It compares your project with the slot it is about to be deployed to and prints every mismatch — and every comparison it could not make:

• PHP version, with a major-version gap graded high because it reliably breaks a site and a minor gap graded lower, because grading everything as critical teaches people to skip the warning.
• Whether the slot can switch to the version you built on, whether the slot's PHP is past end of life, and whether the machine has applied the version or merely been told.
• Your project's size and file count against the disk and inode headroom actually left on the slot — a WordPress tree can run out of files while well under its disk cap.
• The WordPress versions on each side, whether the slot has finished provisioning, and whether a repository is connected to push to.

It warns; it never blocks. Every finding is overridable with zinnector push --force, because you know things about your own site that a checker does not. A comparison that could not be made is reported as unknown, never as a pass, and the summary always says how many there were. By default the local PHP version is the one declared in zinnector.json; --probe boots the local runtime and measures it instead. --strict exits non-zero on unknowns too, which is what a CI gate wants.

Push

zinnector push

push runs the pre-flight, pushes your commits, triggers the deploy and watches it to completion, printing the final status and the deployed commit. --dry-run does everything except the deploy; --no-wait triggers it and exits; --no-git deploys whatever the platform already has without pushing. If the deployed commit is not the one that was just pushed, it says so.

When something goes wrong

zinnector deploys example.com        # deploy history — status, commit, trigger, message
zinnector logs example.com --build   # the build log of the most recent deploy
zinnector logs example.com --error   # the site's error log
zinnector deploy example.com         # redeploy what the platform already has
zinnector ai "why is my deploy failing?"

zinnector ai runs on the platform against your own account, so it can see the same deploy history and logs. From inside a project it sends the project's shape — directory names, versions and the site id — and never file contents.

Related

• Getting started · Local development · Command reference · Troubleshooting