Deployment, tenancy and security

Hosted or self-hosted

Quasar is one product, deployed two ways:

• Hosted: a multi-tenant service, where each organization is a tenant.
• Self-hosted: on your own infrastructure, by default with a single tenant.

The choice is a configuration of the installation, not a different edition. Everything in this guide applies to both unless it says otherwise.

What a tenant is

A tenant is one organization's walled-off space: its people, projects, documents and settings. Nothing belongs to two tenants, and a person signed into one tenant sees nothing of any other.

Above the tenants, the operator of an installation manages it from a separate console:

• instance settings, mail and sign-in;
• background jobs and backup status;
• the platform audit log;
• the product guide;
• on the hosted service, the tenants themselves.

Inside the application, an operator can look into a tenant only through a "view as" session. It is read-only, as a member the operator chooses, for at most an hour, marked with a banner, and recorded in both the tenant's and the platform's audit log.

Where the hosted service runs: in the European Union, on Amazon Web Services in Ireland. A self-hosted installation keeps its data wherever it runs.

What an installation needs

• The application, a single container image. It serves the web app, the REST API and the MCP server.
• The rendering worker, from the same image. It renders each published documentation release once to PDF, Word, HTML and Markdown. It is required, and must see the same file storage as the application.
• PostgreSQL. All data lives in it.
• File storage: a local volume or any S3-compatible storage. Files are always served through the application or through short-lived signed links, never as public bucket addresses.
• Optional:
  • antivirus scanning with ClamAV, off until configured;
  • email over SMTP or Amazon SES, for deadline reminders and password resets.

Tenant isolation

Isolation between tenants is enforced by the database itself, through PostgreSQL row-level security. It is enabled and forced on every table that holds a tenant's data.

• The application connects with a database role that cannot bypass it.
• Every request runs in its tenant's context.
• Filters written in the application's queries are defence in depth, not the boundary.
• Isolation is tested against a real PostgreSQL in every release.

Signing in

An installation chooses its sign-in provider:

• Quasar's own accounts: password and second factor, with password reset by email.
• An OpenID Connect provider: your organization's single sign-on.

Who may enter is decided by the identity the provider asserts, never by an email address alone. A person reaches an organization by:

• an invitation;
• an existing identity;
• membership the provider vouches for.

Sessions are kept on the server, in a cookie that carries no personal data.

Second factor and step-up

• Methods. An authenticator app (TOTP) or a security key. There are no SMS codes.
• Policy. An organization can require a second factor of every member, and new organizations start with it required. Administrators see who is enrolled, and can reset a member's factor; the reset is audited.
• Step-up. Sensitive actions ask for a fresh second factor, among them creating API keys, lowering data retention and exporting personal data.

API keys

• A key acts with exactly its owner's permissions, never more.
• Keys are shown once, expire after 90 days by default, and can be revoked at once.
• A read-only key is enforced by the database: its transactions cannot write.
• Each key is rate-limited, so a runaway script slows down instead of degrading the service for others.

Permissions

• Organization roles: Admin, Member and Viewer.
• Project roles: Project manager, Member and Viewer.
• Divisions and teams can adjust access, but the project has the final word.
• Hidden versus refused. A project someone may not see does not appear to exist. A refusal is given only where the thing is visible but the right is missing.

Records

• Tenant audit log: administrative actions, sign-ins, sign-outs and failed sign-ins.
• Event logs: every change to issues, documents and sprints, with who made it and whether an agent acted for them.
• Platform audit log: every operator action.

Files and delivered documents

• Attachments and uploads are size-limited and type-checked, and scanned when antivirus is configured. They are always offered as downloads, never displayed inline.
• Exported documents are self-contained:
  • they carry a strict content-security policy;
  • they never load anything from the network;
  • they refuse to deliver text marked internal.

Data export, retention and erasure

• Personal data export. Every person can export their own data as JSON, for the rights of access and portability.
• Retention. Deleted items stay in a project's trash for a period the organization sets, from 7 to 365 days, then are purged.
• Erasure. Erasing a person anonymizes them in place, so histories stay consistent without naming them.
• Leaving the hosted service. An organization can be exported in full, then deleted after a grace period.

How the software is built

• Stack: TypeScript, PostgreSQL and Docker.
• Tests:
  • 100% automated test coverage is the minimum for every change;
  • on top of it: mutation testing of critical logic, property-based tests, golden tests for money, and tenant-isolation tests on a real database.
• Dependencies are audited for known high-severity vulnerabilities before every release.
• Releases are numbered by date, YYYY.MM.N, and every running build shows its version and commit.