Bluesky Custom Feeds

Automating DNS and Profile Redirections for Bluesky Identities

As part of my work experimenting with the Bluesky AT Protocol, I developed two AWS-based solutions:

  • Automating DNS TXT updates for AT Protocol verification.
  • Redirecting subdomains to Bluesky profiles for simpler identity sharing.

The first project was built in collaboration with a Bluesky community member. The second came as a direct request from another user, who wanted short branded links for Bluesky handles. Together, these systems show how cloud infrastructure can make decentralized identities easier to manage and share.

Automating DNS Updates with AWS Lambda, Route53, and API Gateway

For AT Protocol verification, each domain needs a _atproto TXT record that points to the user’s DID. Manually updating these records can be tedious, so I built a serverless workflow:

  • AWS Lambda: Parses requests and updates DNS.
  • Route53: Stores DNS TXT records for bsky.ar.
  • API Gateway: Exposes a public HTTPS endpoint.
  • IAM Role: Grants Lambda permissions to modify Route53 records.

Using AWS Route 53 for DNS, combined with API Gateway and Lambda, made it possible to handle requests dynamically, while CloudFront ensured fast and reliable content delivery across regions. This approach avoided the need for a dedicated server while still enabling custom routing and integrations.

Project Focus

  • Automation: Enable users to self-service DNS verification via a simple endpoint.
  • Serverless Design: Minimize infrastructure management by relying on Lambda and API Gateway.
  • Reliability: Debugging and logs handled via CloudWatch, with POST-only requests to ensure safe operations.
  • User Collaboration: Developed with input from a Bluesky community member to match real-world verification workflows.

Architecture

The system is structured as a serverless AWS stack:

Bluesky DNS Update Workflow DNS Update Workflow API Gateway (AR) POST /update-dns Lambda #1 AR DNS TXT Update Route53 AR

The Lambda function accepts JSON input like: 

{
  "subdomain": "example",
  "did": "did:example:123456789abcdef"
}

and creates the corresponding TXT record _atproto.example.bsky.ar.

✅ This allows any Bluesky user under the domain to self-service their verification by calling the endpoint.

Redirecting Subdomains to Bluesky Profiles

The second system focused on improving user-facing identity links. Instead of sharing long Bluesky URLs, I configured a system where any subdomain of bsky.uy redirects directly to the matching Bluesky profile.

Examples:

The stack uses:

Bluesky Redirect Workflow Redirect Workflow Browser Lambda #2 Redirect Profile Redirect

Simplified logic:

function handler(event) {
  var host = event.request.headers.host.value;
  var sub = host.split('.')[0];
  if (sub !== 'www') {
    return {
      statusCode: 302,
      headers: {
        location: { value: `https://bsky.app/profile/${sub}.bsky.uy` }
      }
    };
  }
  return event.request;
}

One limitation is that link previews don’t always carry over when redirects happen. To fix this, I plan to extend the system to dynamically inject Open Graph tags, so each subdomain can display avatars and profile metadata.

Closing Thoughts

Both of these projects highlight the developer-first nature of Bluesky. With just a few AWS primitives, it’s possible to:

  • Automate AT Protocol verification at scale.
  • Provide branded, human-readable profile links that integrate smoothly with the ecosystem.

By collaborating with Bluesky users and responding to their requests, these experiments aim to make decentralized identity more accessible, flexible, and user-friendly.

🏠 Home Email LinkedIn GitHub