> Complete content index: https://sondelali.com/llms.txt

# Conjoin

> Conjoin is a backend platform of eight independent services behind one SDK, covering AI, auth, messaging, storage, async infrastructure, billing, databases, and compute.

URL: https://sondelali.com/projects/conjoin
Category: Technology

<Frame>
  <img src="/images/projects/conjoin/banner.png" alt="Conjoin: Build better apps with Conjoin, faster" loading="eager" />
</Frame>

<Callout type="info" title="My role">
  Conjoin is the developer platform at [Delalify](/projects/delalify). I designed and built the systems it runs on, which are the service routing, the multi-region deployment topology, and the cross-service coordination that lets the eight services call one another. I wrote the networking layer underneath them as well.
</Callout>

Conjoin is a backend platform of eight independent services behind one SDK. Each service runs on its own, and a call that crosses two of them takes the same routing, authentication, and retry path as a call that stays inside one.

## The eight services

<Tabs>
  <Tab title="AI">
    The AI service ties every other Conjoin service together. It passes private data to a model while enforcing per-user access controls, and it redacts <Tooltip tip="PII stands for personally identifiable information, meaning any data that can identify a specific person, such as a name, email address, or phone number.">PII</Tooltip> before that data reaches a third-party provider. It runs inference across several models, orchestrates workflows declared rather than coded, indexes Storage without an ETL step, and applies budget limits per project, team, or user. The provider stays pluggable, so a task can move to a different model without its calling code changing.
  </Tab>
  <Tab title="Auth">
    Auth covers passwordless login, OAuth with more than 30 providers, enterprise SSO through SAML 2.0 and OIDC, directory sync through SCIM 2.0, multi-factor authentication, <Tooltip tip="RBAC stands for role-based access control. It grants each person permissions based on the role they hold, such as admin or viewer, so access rules are set once per role rather than per person.">RBAC</Tooltip>, session management, and threat detection through Auth Guard. It verifies a token in under 10ms, which is what lets every other service check authorisation on the request path itself.
  </Tab>
  <Tab title="Messaging">
    Messaging sends transactional and marketing email and SMS. It versions templates, batches operations under a rate limit, issues verification codes, tracks delivery in real time, and handles GDPR-compliant unsubscribes. Delivery state returns through Relay, so a failed send retries without the calling service polling for it.
  </Tab>
  <Tab title="Storage">
    Storage replicates files across regions in the US, the EU, and Asia. It accepts resumable uploads of up to 4TB, processes an image on request, and issues signed URLs, object versions, and lifecycle rules. Auth supplies its access control directly, so a file carries the permissions of the account that owns it.
  </Tab>
  <Tab title="Relay">
    Relay is the asynchronous side of the platform. It runs durable pipelines that persist their state, queues with priorities and rate limiting, pub/sub event subscriptions, real-time broadcast channels with presence tracking, scheduled tasks, managed Redis clusters, full-text search, and approval gates where a person has to sign off. A queue delivers a message in under 100ms while taking more than 500,000 messages a second, which is the throughput the rest of the platform is built against.
  </Tab>
  <Tab title="Billing">
    Billing models a plan as a bundle of recurring, one-time, and metered prices, and a single call charges a customer against it. It covers subscriptions, trials, proration, invoicing, <Tooltip tip="Dunning is the automated process of retrying failed payments and reminding customers to update their payment details before a subscription is cancelled.">dunning</Tooltip>, and tax calculation. It routes each payment across several providers, so an outage at one of them leaves the charge standing.
  </Tab>
  <Tab title="Database">
    Database runs managed Postgres and SQLite, with automated backups, point-in-time recovery, read replicas, connection pooling, automatic failover, and scaling that takes no downtime. Conjoin Live streams database changes to a frontend or a backend in real time through Live Collections, Live Views, and Change Streams.
  </Tab>
  <Tab title="Runtime">
    Runtime runs code, hosts applications, and holds AI agent sessions through three lifecycle modes in one service. An ephemeral execution starts in under 500ms. A persistent session lasts up to 24 hours, gives an agent a writable filesystem, and streams its output as it runs. Application hosting covers git-based deployments, auto-scaling, scale-to-zero, and custom domains with automatic TLS. Every container already holds the Conjoin SDK, so the code inside it reaches storage, databases, and messaging without handling any credentials.
  </Tab>
</Tabs>

## How eight separate services behave like one

The eight services run as separate programs on separate machines, though a developer calling them should never have to think about that, and a single request will often touch three of them in turn as it checks who the caller is, writes a file, and queues a job for later. Each hop between one service and the next is a place where the caller's identity can be lost, where the call can cross a continent to reach the data it needs, or where one slow service can hold up the two that are waiting on it.

Rather than solving those three problems inside every service, I built the answers into the layer beneath the SDK. A routing layer there chooses which copy of a service to call from where the data already is, while the request itself keeps one identity from its first hop to its last, which spares the third service from having to ask the first who sent it. A single retry policy covering every hop then means that a service failing for a second will not fail the whole request.

## What an AI agent can do with it

The SDK gives an AI agent the same single integration to every service that it gives a person. The CLI is built on that same SDK and runs agents of its own, so it can carry out a plain request across the whole platform. AI coding tools such as Claude Code, Cursor, and Codex drive the CLI directly: an agent in your editor or terminal can set up authentication, send messages, query a database, run code, and manage billing. The MCP server exposes the platform over the Model Context Protocol for any agent that supports it.

Conjoin also runs agents. [Runtime](https://conjoin.delalify.com/products/runtime) gives them persistent sessions with writable filesystems and the SDK already in place, while the AI service handles model inference across providers. An agent can therefore reason, call a model, and act on real infrastructure without leaving the platform.
