Skip to main content
The SDK is backend-agnostic: it talks to whatever apiUrl you give it, over the frozen /v1 contract. Self-hosting means implementing that contract on your own backend and pointing the SDK at it.
Everything else in these docs — mounting, autosave, the renderer’s auth modes — is identical to the managed cloud.

​
What your backend must provide

1

The /v1 document endpoints

List/create/read/update/delete plus the shared-token read, exactly as specified in the Documents API. Paths are rooted at <apiUrl>/v1/….
2

Bearer-token auth

The editor sends Authorization: Bearer <token> with whatever your getToken returns. On your own backend you control both sides, so this can be the standard embed-token exchange or any token scheme of yours — the SDK only requires that a 401 means “refresh via getToken and retry once”. If the token is a JWT with an exp claim, the SDK also refreshes proactively before expiry.
3

Signature verification (renderers only)

For cross-user reads, verify ?sig=&exp= as HMAC-SHA256 over "<doc_id>|<exp>" — see Signatures.
4

Quran / hadith content

The editor’s insertion dialogs read /v1/quran/… and /v1/hadith/…, so your backend needs to serve those endpoints and source the underlying datasets. On the managed cloud they are hosted and kept current for you.
5

Image storage

The upload/confirm/url image endpoints backed by S3-compatible storage, if your documents include images.

​
When to choose this

While Qirtaas seems simple, the backend that powers it isn’t. To self-host it, you need:
  1. Elasticsearch for content API
  2. S3-compatible storage
  3. Background job processing for content API syncing
You should self host if you already have a cluster that you can deploy these services to, or if you don’t need all of the features in Qirtaas. For the trade-offs, see Self-host vs Cloud.