SiteOps.

Connect Bluesky to SiteOps

There is a calmer corner of social right now, and it is called Bluesky — short posts up to 300 characters, a feed people actually read, and a crowd that skews thoughtful. For a small brand it is one of the friendliest places to show up: no ad noise to shout over, and no fees for tools that post on your behalf.

That last part matters. Where X charges for API access and Meta routes everything through consent screens, Bluesky uses app passwords — a separate password you generate inside the Bluesky app just for one tool. It signs SiteOps in without revealing your real password, it cannot change your account settings, and you can revoke it in one tap whenever you like.

Connected, it becomes the lightest channel in the set. Bluesky drafts — including the ones your calendar events and routines order — wait in the Posts tab already trimmed to 300 characters; approve one and it takes a Calendar slot, publishes on its own, and its likes, reposts and replies come back to the Social card.

One key, copied once

Set it up, step by step

0 of 7 done

    1. Settings
    2. Privacy and security
    3. App passwords
    1. Settings
    2. Bluesky
    3. Connect
  5. What a Bluesky post carries — 300 characters, media optional

    The green status in Settings only proves the sign-in. A real post is the end-to-end test.

  6. The single record that makes your domain your handle

    SiteOps does not mind which handle you use — if you switch later, update the handle field in Settings and keep the same app password.

    1. Settings
    2. Account
    3. Handle

Let an agent do it

An agent with access to your DNS can set up the optional custom-domain handle for you — it is a single TXT record.

Prompt for your agent
Set my domain as my Bluesky handle.

1. My domain is <yourbrand.com>, managed at <my DNS provider>.
2. In my DNS zone, add a TXT record:
   host: _atproto.<yourbrand.com>
   value: did=<the did:plc value Bluesky shows me under Settings, Account, Handle, "I have my own domain">
3. Keep the TTL at the provider's default and save.
4. Confirm the record resolves (for example: dig TXT _atproto.<yourbrand.com>) and tell me when it does, so I can press Verify in Bluesky.

You still do the rest yourself: creating the Bluesky account, generating the app password on the App passwords screen, pasting it into SiteOps, and pressing Verify in Bluesky — an agent should never be handed your app password, and Bluesky's screens need your own signed-in session.

If something does not work

SiteOps says the handle or password is invalid
Nine times out of ten the real account password was pasted instead of the app password. Go back to Settings, Privacy and security, App passwords in Bluesky, create a fresh one — four dash-joined blocks — and paste that. Also check the handle is complete: name.bsky.social, no @ in front.
What exactly is my handle?
The full address after the @ on your profile. For most accounts that is name.bsky.social; if you set up a custom domain handle it is the bare domain, like yourbrand.com. Either works in SiteOps — just enter it without the @.
Posting worked, then suddenly stopped
The app password was most likely revoked or deleted on Bluesky's App passwords screen — that is the designed off switch, and it fails exactly like this. Generate a new app password named SiteOps and paste it into Settings; the connection resumes.
My post came out shorter than the draft
Bluesky's hard limit is 300 characters, and SiteOps trims drafts to fit before you approve them. If the trim reads badly, edit the draft in the Posts tab before approving — what you approve is exactly what publishes.
The custom domain handle won't verify
DNS changes take time to spread — from minutes up to an hour or two. Check the TXT record sits at _atproto.yourdomain.com (the _atproto part is easy to drop) and that the value starts with did=. Then press Verify again. Your .bsky.social handle keeps working the whole time.

Set up once, see everything every morning

Get started