Hardened by default.

Hosting and isolation

Meletema runs on Laravel Cloud's managed infrastructure, which provisions application servers, managed databases, and object storage on top of major cloud providers in US regions. Customer environments are logically isolated per organization through the application's tenancy model; data is never co-mingled between organizations at the query layer.

Encryption

• In transit. All public endpoints require HTTPS with TLS 1.2 or higher. HSTS is enabled and HTTP requests are upgraded automatically.
• At rest. Database volumes and object storage are encrypted with AES-256 keys managed by the underlying cloud provider.
• Application secrets. Tokens, LTI tool keys, and OAuth client secrets are stored as Laravel-encrypted columns or environment-injected secrets, never in plaintext source control.

How users sign in

Meletema uses Laravel Fortify for authentication. Passwords are hashed with bcrypt; brute-force attempts are throttled per IP and per email. Users may enable a second factor (TOTP) or register a passkey (WebAuthn) on their account. Students reached through an LMS launch (LTI 1.1 or 1.3) authenticate via signed launch claims and never establish their own credentials in Meletema.

Role-based access

Each organization has admin and instructor roles, enforced through Spatie Laravel Permission and per-resource Laravel policies. Admins can manage members, billing, branding, and LMS connections; instructors can author decks, see student progress within their own sections, and publish to the LMS. No user can read another organization's data — every query is scoped through the authenticated user's organization membership.

Tool key management

For LTI 1.3, Meletema generates an RSA keypair per tool installation. The private key never leaves the application; the public key is served at a JWKS endpoint for the LMS to verify our outbound JWTs. Inbound launch JWTs are validated against the platform's published JWKS on each request. For LTI 1.1, OAuth 1.0a signatures are verified using consumer-key/secret pairs stored encrypted at rest.

CSRF, XSS, SQL injection

The Laravel framework provides automatic CSRF tokens on all state-changing requests (except LTI launch endpoints, which use signed JWTs instead). Output is escaped by default in every Blade template, and all database queries use parameter binding through the Eloquent ORM. Content Security Policy headers restrict the origins from which scripts, styles, and frames can load.

Stripe-only billing

All billing is processed by Stripe through Laravel Cashier. Card details are tokenized in the customer's browser by Stripe Elements and posted directly to Stripe — Meletema servers never see a primary account number, CVV, or expiration date. Stripe is PCI-DSS Level 1 certified.

Backups and monitoring

• Backups. Daily automated database snapshots retained for 30 days; point-in-time recovery available within the most recent 7 days.
• Logging. Application logs and exception traces are captured centrally. Logs containing personally identifiable information are retained no longer than 30 days unless required for an active investigation.
• Patching. Laravel, PHP, and direct dependencies are kept within one minor version of upstream stable. Security advisories from Composer Audit and GitHub Dependabot are triaged within 48 hours.

When something goes wrong

We maintain an internal incident-response runbook covering detection, containment, eradication, recovery, and customer notification. Confirmed unauthorized access to organization data triggers notification to the affected organization's admins within 72 hours, in accordance with applicable state and federal breach-notification laws.

Report a vulnerability

If you've discovered a vulnerability in Meletema, please report it through our support page with the subject "Security report." We acknowledge reports within two business days, do not pursue good-faith researchers, and credit reporters in our release notes when they consent.