Knowledge base

Working on a site somebody shared with you

A site's owner can hand one site to a developer by email — not their account, not their billing, not their other sites. Both halves: sharing and revoking it from the dashboard, and pulling the site down with zinnector login, clone and dev, database included — plus what each role can and cannot do.

A site's owner can give you access to one of their sites — not their account, not their billing, not their other sites — and you work on it with your own Zinn Digital® login and the free Zinnector® CLI. This guide is both halves of that: what the owner does, and what you do.

If you have not used Zinnector® before, Getting started with Zinnector® installs it in about two minutes. Nothing here needs you to buy hosting.

For the site's owner — sharing one site

  1. Open the site in your dashboard and go to Security.
  2. In Who else can reach this site, choose Share this site.
  3. Type the developer's email address. They do not need an account yet — if they have never signed in, they get an invitation and the access begins the moment they accept it.
  4. Choose a role:
  • Viewer — can look, and can change nothing.
  • Editor — the role a developer normally needs. They can change the site's files, use wp-admin, and download an archive of the site to work on locally. That archive includes the database.
  • Manager — everything an editor can do, plus restoring a backup.
  1. Give a reason and, if the work has an end date, an expiry. The grant simply stops counting on that date; you do not have to remember to remove it.
  2. Save.

Whatever you choose, a collaborator can never delete the site, see your billing, or reach any of your other sites.

What "the archive includes the database" means

An editor or a manager can take a copy of the site to work on, and a copy of a site is its files and its database. A WordPress database holds whatever your visitors have given the site — commenter names and email addresses, customer accounts, WooCommerce orders and delivery addresses, form submissions.

That is normally exactly what a developer needs: without it they are looking at your theme against an empty site. It is worth knowing about, because it is real personal data and the people it belongs to are your customers, not ours.

Two things follow, and the platform does both for you:

  • Every export is in your audit log. Open Audit log and look for site.backup.exported. Each row names who took it, when, and whether that archive carried the database. You do not have to ask.
  • You can end it at any moment. Revoking is instant — see below.

If you would rather they worked without the database, tell them to add --no-database when they pull; it is one flag and the rest works the same.

For the developer — getting the site onto your machine

1. Install Zinnector®

npm install -g zinnector
zinnector --version

You need Node 24 or newer. node --version must print v24 or higher.

2. Sign in as yourself

zinnector login

This opens your browser and signs you in with your own Zinn Digital® account — the one the invitation was sent to. You never need the owner's password, and they never need to give you one.

Check what you were given:

zinnector sites

You will see exactly the sites you were shared, and nothing else. If the list is empty, the invitation has not been accepted yet, or the grant has been revoked or has expired.

3. Pull the site down

zinnector clone client-domain.com
cd client-domain.com

clone makes a local project from the hosted site. It takes:

  • wp-content — the themes, plugins, mu-plugins, languages and media that are the site's own work;
  • the database, written to database.sql in the project.

It deliberately leaves behind WordPress core (your local runtime supplies the right version), wp-config.php (it holds the live site's database password), and any media that has been offloaded to object storage.

Every run prints exactly what it took and what it left, with counts. If you want the files only, add --no-database.

Already have the project and just want the latest? Run zinnector pull inside it.

4. Run it locally, with the real content

zinnector dev --runtime docker

On the Docker runtime this imports database.sql, rewrites the site's URL to your local address, and opens the site with the customer's real content in it. Log in with the site's own WordPress accounts.

The default runtime — WordPress Playground, which needs no Docker — is faster to start and does not import the database; it will tell you so rather than quietly starting empty. Use it when you are working on code and do not need the content.

5. Look after the copy you have been given

database.sql is a live site's database. Zinnector® adds it to your project's .gitignore the moment it writes it, so an absent-minded git add -A cannot publish someone's customers to a repository. Leave that line alone, and delete the file when the job is done.

What a collaborator can and cannot do

| | Viewer | Editor | Manager | |---|---|---|---| | See the site and its settings | ✔ | ✔ | ✔ | | Change files, use wp-admin, deploy | | ✔ | ✔ | | Pull the site, database included | | ✔ | ✔ | | Restore a backup over the live site | | | ✔ | | Delete the site | | | | | See billing or invoices | | | | | Reach the owner's other sites | | | |

The last three rows are blank for every role. They are not a setting.

Ending access

The owner opens the site's Security section and chooses Revoke beside the person's name. It takes effect immediately: the next Zinnector® command that developer runs cannot see the site, and neither can anything else they hold.

An expiry does the same thing on a date, without anyone having to remember. If you set one when you shared the site, you are already finished.

When something does not work

  • zinnector sites shows nothing. The invitation has not been accepted, or the grant was revoked or expired. Ask the owner to look at the site's Security section — a pending invitation is listed there.
  • zinnector pull says the site has no recent backup. The pull takes a fresh one if the plan allows it, and asks first. If the plan does not include on-demand backups, raise --max-age to accept an older one.
  • zinnector dev starts an empty WordPress. You are on the Playground runtime, which does not import a database. Run zinnector dev --runtime docker.
  • The local site keeps redirecting to the live domain. The import rewrites the site URL; if that step failed, the command says so and prints the wp search-replace line to run.

More errors and their fixes: Zinnector® troubleshooting.

All developer docs

Latest from the blog

What we have been writing about hosting, SEO and running sites at scale.

SEO and Link Building from the Hosting Layer: A 2026 Operator's View

How hosting shapes indexing and link equity in 2026: keeping pages indexed, vetting aged domains before you build on them, link building without a footprint, and an honest line on what infrastructure can and cannot do for SEO.

Read the post

Making WordPress Fast and Secure: A Performance and Plugin Checklist

A practical checklist for fast, secure WordPress: server-level caching, a per-site object cache, the handful of plugins worth running, keeping the stack current, and the WooCommerce pages you must never cache.

Read the post

How to Choose Managed Web Hosting in 2026: A Buyer's Guide

What actually separates good managed hosting from a cheap box with a control panel — migrations, backups, isolation, real caching and honest scaling — and how to judge it before you commit.

Read the post

Read the blog

Still stuck?

Support is included on every plan, the desk is open 24 hours a day, and you can write to us in any of our 58 languages — we answer you in yours.

Contact support All articles