Getting started

When you sign in to a fresh workspace, the dashboard shows a setup checklist and a guided walkthrough. Every step is skippable, the wizard survives page reloads, and each step checks off automatically as soon as the real thing exists — even if you did it another way. Your editors never see any of this; they only need an email address.

1. 1

   Create an account and a workspace

   Sign up with your email address on the sign-up page and accept the terms — PullPress sends you a magic link, no password to remember. Your first workspace groups your sites, your team and your billing. (Logging in with an address that has no account doesn't create one; you'll get an email pointing you to sign-up instead.)

2. 2

   Connect a website (or start with a trial site)

   No repository yet, or just looking around? Click Create a trial site — in the wizard, or on the empty dashboard. You get a sample site with a few posts, two pages and opening hours, in your language, and you can write, review and publish right away. Its content is kept in PullPress instead of a GitHub repository, so publishing doesn't update a real website yet; everything else — drafts, review, scheduling, history, media, inviting your team — works exactly as it will later. A workspace has one trial site, and it doesn't count towards your plan's site limit or bill. A trial site holds about 75 MB of photos and text; photos you upload but never save are cleared after two days.

   When you're ready, click Connect to GitHub on the trial site. After installing the App, pick a repository and leave Move trial site to this repository ticked: PullPress commits the trial site's files to the repository's main branch in one commit (files with the same name are replaced, the rest of the repository is untouched) and the site keeps its members, settings and history. Publish or withdraw open changes first — they only exist in PullPress — and the repository needs at least one commit (a README is enough).

   The wizard sends you to GitHub to install the PullPress GitHub App on the repository that holds your site's content — you can scope it to a single repo (see GitHub App setup for the exact permissions) and asks you to authorize PullPress for your GitHub account, so PullPress can confirm the installation really is yours. Back in PullPress you first see which account the installation covers and how many repositories it can reach — with a one-click link to change the installation on GitHub if the App landed on the wrong account — and then pick the repository as your first site. Cancelled the GitHub flow halfway? You land back on a gentle retry note, not an error.

3. 3

   Confirm your content structure

   PullPress reads the files that are already in the repository and proposes the collections and fields your editors will see — in your own language. Detection recognizes Astro content collections (including sites served under a base subpath), Hugo (leaf and branch bundles, a custom contentDir, and data/ files as editable data collections), Jekyll (_posts plus every custom collection listed in _config.yml), Eleventy, Next.js content folders (including contentlayer's contentDirPath) and date-nested bundles like content/2026/06/post/index.md — along with each collection's frontmatter fields and format. In a monorepo with several sites you pick which project to configure, and when nothing is found the setup card says exactly where it looked and how to configure things by hand. Coming from Decap CMS (Netlify CMS)? Your existing config.yml is detected and converted — see Migrate from Decap CMS. Migrating from WordPress? Pick Import from WordPress on the same setup card: PullPress creates a blog configuration and takes you straight to uploading your export file (Tools → Export in WordPress) — your published posts arrive as a single change you review before it goes live. See what the WordPress import covers.

   Confirming commits a single pullpress.config.yml to your repository (nothing is published to your website; a .yaml extension works too). Sites whose content uses TOML or JSON frontmatter keep their format — PullPress detects it and writes every entry back the way it found it. You can also write or tweak the configuration by hand — a minimal blog config looks like this:

   version: 1
   media: { folder: public/uploads, public_path: /uploads }
   collections:
     - name: blog
       label: Blog posts
       type: folder
       folder: content/blog
       fields:
         - { name: title, label: Title, type: string, required: true }
         - { name: date,  label: Date,  type: date, default: now }
         - { name: body,  label: Body,  type: markdown }

   

   The full set of options is covered in the configuration reference.

4. 4

   Invite your first writer — or a whole team

   Add a writer by email. Someone new to PullPress gets an invitation with a personal sign-in link (single use, valid for seven days) that signs them in and lands them straight on your site — no second email to wait for, no GitHub account, no repository access, no setup on their side. An expired link simply offers to send a fresh sign-in email. Someone who already has a PullPress account first accepts the invitation under Invitations (a banner on their dashboard points there); until they do, nothing is shared with them. Choose a role per person: editors draft and submit, approvers review and publish, viewers only read — see Roles & permissions for the full matrix. This step also completes by itself if a second person joins your workspace any other way.

   Onboarding a client team? The same invite field takes one address or a whole list at once (commas, newlines, a spreadsheet column or CSV rows with names, even Name <email>) with one role and optional collection access for everyone — each row reports its own outcome, so one typo never sinks the batch. Invitees who haven't logged in yet show up as pending invites with resend/revoke and a bulk resend. An invited editor's first login lands on their site with a short, dismissible "how this works" explainer, and every site carries a brand-neutral in-app writers' guide you can share ahead of time. On white-label (Agency) workspaces the whole welcome — invitation email, login page, first session — carries your client's brand, never ours.

   

5. 5

   Publish a first change

   The wizard prompts you to make one small edit and approve it yourself, so you experience the loop your team will use every day: a saved draft becomes a branch in your repo, submitting opens a pull request, and approving merges it — published through your normal build and deploy. Sites can also publish instantly or require the final merge on GitHub; see publishing flows below.

6. 6

   Workspaces, seats & plans

   Everything lives inside a workspace (your agency) with its own monthly subscription. People who only read or approve are always free. Plans: Free (1 site, 1 writer), Pro (per writer/month, up to 3 sites), Agency (a monthly base fee plus a fee per active client site, unlimited writers, white-label branding included). Adding or removing a writer (Pro) or connecting and archiving a site (Agency) adjusts the bill automatically, prorated by Stripe.

   On Agency, archiving a site (site settings) makes it read-only — everything stays browsable, but saving and publishing are off — and removes it from the bill. Unarchive it anytime to pick up where you left off.

   A free account has a single workspace; several separate workspaces (each its own team and bill) come with a paid plan. Owners manage it all from Workspace settings — upgrade, downgrade or cancel anytime (cancellations take effect at the end of the billing period). Prices exclude VAT, which Stripe adds at checkout; business customers can enter their VAT id. If a payment fails, the plan keeps working while Stripe retries, and the owner gets an email and a banner with an Update payment method button.

   

Managing your sites

After the first site, everything about connecting websites lives on Sites & GitHub in the top bar (workspace owners and admins only):

• Connect site installs the GitHub App on another repository and adds it as a site.
• Existing GitHub connections lists the GitHub accounts the App is already installed on. Add site picks another repository from that installation without a round trip through GitHub; Disconnect (owners, once no active site uses it) unlinks the installation from this workspace without changing anything on GitHub. Connect an existing installation is for an App a colleague or organization admin already installed: you confirm your access by signing in with GitHub instead of installing again (see GitHub App setup).
• Create a trial site adds the one-click sample site described above, if the workspace doesn't have one yet.
• Every site row shows its repository and branch, how many changes wait for review and how many drafts are open, and an Archived badge where relevant. The ⋮ menu jumps to the site's settings or members and archives (or unarchives) it. On the Agency plan the page also shows the number of active client sites and the projected monthly price.

Publishing flows

Every site has a publishing flow — chosen when you connect the site and changeable anytime under the site's settings. It decides what happens when an editor submits a change:

• Approval in PullPress (the default) — submitting opens a pull request; an approver reviews the change in PullPress and publishes it with one click, which merges the pull request. Right for most teams: writers never touch GitHub, and someone still looks before anything goes live.
• Publish directly — submitting goes live immediately, with no approval step. Pick this for small, trusted sites where the writer and the approver are the same person.
• Extra approval on GitHub — approving in PullPress opens the pull request, but the final merge happens on GitHub through your own review process. Pick this for large sites with branch protection rules or required status checks.

Importing from WordPress

Site admins can bring a WordPress blog over from the site's Import page (also linked from site settings). In WordPress, go to Tools → Export and download the export file (.xml), then upload it and pick the collection to import into. Know what to expect:

• Only published posts are imported — up to 200 per run, from an export file of at most 4 MB (split a larger export in WordPress). Pages, drafts and comments are left out.
• Each post keeps its title, date, tags and categories (where your collection has those fields) and its text, converted to Markdown.
• Media files aren't copied. Images in posts keep pointing at your old WordPress site, so keep it online until you've re-uploaded them through the media library.
• A post whose file already exists is skipped, never overwritten. Everything else arrives as one change to review before it goes live.

Self-hosting PullPress? The server-side setup (database, GitHub App credentials, email) is covered by SETUP.md in the repository — this guide is about the in-app experience.