> For the complete documentation index, see [llms.txt](https://islamu.gitbook.io/islamu-event/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://islamu.gitbook.io/islamu-event/readme.md).

# ISLAMU Event

Evaluate, deploy, and operate a self-hosted event platform for communities and organizations.

ISLAMU Event is a self-hostable platform for public event discovery, organizer workflows, registration and admission, paid events, administration, notifications, integrations, and selective open-protocol federation.

{% hint style="warning" %}
**Active Pre-Release Development:** ISLAMU Event has **no official release yet**. We are actively fixing startup bugs and preparing for our very first release soon! Pre-built container images and release tags are not yet published.
{% endhint %}

## Who this documentation is for

Use this site if you are:

* evaluating whether ISLAMU Event fits an organization or community;
* responsible for a self-hosted deployment;
* operating identity, authorization, backups, upgrades, email, payments, or integrations;
* integrating through HAL/REST, webhooks, MCP, forms, or AT Protocol records;
* contributing to the repository and its governed release process.

This is not an attendee guide. User interfaces remain discoverable through the product; these pages focus on adoption, deployment, operations, security, and integration.

## Start with the deployment decision

| Path                 | Best fit                                                       | Durable state                                                    | Important boundary                                                                             |
| -------------------- | -------------------------------------------------------------- | ---------------------------------------------------------------- | ---------------------------------------------------------------------------------------------- |
| Standalone container | Evaluation, small installations, lowest operational load       | SQLite plus the privacy-erasure authority file and local storage | One API replica; preserve every durable file during backup and restore                         |
| Split Docker Compose | Long-running self-hosting with independently operated services | PostgreSQL and configured service volumes                        | Run initialization and migrations in order; validate the rendered Compose model before startup |
| Coolify              | Teams already operating Coolify and Traefik                    | Same application databases and volumes as the selected topology  | Repository guidance covers Cerbos operations, not a one-click full-platform template           |
| .NET Aspire          | Local development and adopter-owned orchestration              | Resources declared by the AppHost                                | Aspire can target clouds, but this repository does not ship turnkey Azure or AWS templates     |

Kubernetes/Helm, ActivityPub, first-party AT Protocol PDS/AppView hosting, and initial arm64 images are not current supported promises.

## Architecture at a glance

Browser traffic enters through the Blazor BFF. The BFF owns browser session handling and forwards access tokens to the API. The API dispatches application requests through MediatR, persists business state, and emits durable work through outboxes. Local Identity, Keycloak, or AT Protocol can be the primary browser identity authority. Runtime authorization is explicitly selected between Cerbos and local DB-backed RBAC.

Clients do not infer mutation rights from roles or claims. HAL `_links` returned by the server are the source of truth for actions such as edit, delete, check-in, refund, and administration.

## Operational trust model

* Secret and authorization authorities fail closed; they do not silently weaken to fallback providers.
* Tenant resolution and persistence filters fail closed when tenant context is missing.
* Payment and refund state is authoritative only after provider-confirmed evidence.
* In-app notification rows are durable truth; SSE and Web Push are refresh hints.
* Privacy erasure has a separate durable authority whose backup and restore obligations depend on the selected topology.
* Branding never replaces required platform, directory-operator, or tenant legal-disclosure identity.

These are system contracts, not claims of regulatory compliance or religious certification. Deployment-specific law, provider agreements, tax, accounting, accessibility validation, and operating policy remain adopter responsibilities.

## Evaluate in this order

1. Read the [Documentation](https://islamu.gitbook.io/islamu-event/documentation/) overview and choose a deployment path.
2. Review security, tenancy, privacy-erasure recovery, secrets, backup, and upgrade boundaries.
3. Check unsupported capabilities and provider-owned responsibilities against your requirements.
4. Use the [API Reference](https://islamu.gitbook.io/islamu-event/api-reference/) for protocol and integration decisions.
5. Keep the [Self-Hoster & Adopter FAQ](https://islamu.gitbook.io/islamu-event/help-center/) available during installation.
6. Follow the [Roadmap](https://sites.plane.so/views/b8b7d9fced694f5a9d9a546e9d40d988) and upcoming release notes as the first version is published.

## What success looks like

A production-ready adopter can identify every durable data location, resolve every secret from an approved authority, verify identity and authorization health, complete a backup and restore drill, observe `/alive`, `/health`, and `/metrics` safely, and explain which party owns payment, privacy, moderation, and external-provider decisions.

If any one of those answers is unknown, treat the deployment as not ready rather than relying on a silent default.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://islamu.gitbook.io/islamu-event/readme.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.