---
created_by: "Generated by AI gpt-5-codex on 2026-06-06T00:00:00Z. Human review required."
---

# Apache / OVHcloud Deployment Notes

## Scope

This note captures the deployment assumptions for the PHP 8.3 MVP when hosted on an Apache-like OVHcloud environment.

## Updated integration assumptions

- Use a webroot that points directly at `public/`.
- Keep all application code, configuration, and storage outside the webroot whenever possible.
- Keep the current explicit route files:
  - `index.php`
  - `login.php`
  - `app.php`
  - `files.php`
  - `logout.php`
- Do not require framework routing or a separate app server.
- Do not rely on browser-accessible file paths for downloads or uploads.

## Public / private directory layout

- `public/`
  - Apache document root.
  - Contains only public entry scripts and any safe static assets.
  - Must not contain the file storage root or secret config.
- `app/`
  - Private PHP application logic.
- `config/`
  - Private configuration files.
  - `config/auth.local.php` stays out of version control.
- `storage/`
  - Private filesystem storage root for managed files.
  - Must remain outside the document root.

## Rewrite and routing assumptions

- The MVP does not need URL rewriting to function.
- Each public action can remain an explicit PHP entry point.
- If the host later needs prettier URLs, add an Apache-local `.htaccess` inside `public/` only.
- Any optional rewrite rule must preserve the same security boundary:
  - requests still land inside `public/`
  - file operations still go through authenticated PHP handlers
  - direct access to `storage/` remains blocked

## Apache / OVHcloud-specific constraints

- Shared or managed Apache hosting often gives limited control over virtual host config.
- Because of that, the design should work with only a document root assignment and an optional `.htaccess`.
- The safest MVP path is to avoid hard dependence on Apache features beyond:
  - serving `public/`
  - honoring standard PHP entry scripts
  - denying direct web access to private directories through placement, not clever routing

## Architecture changes from the previous assumption set

- No change to the core filesystem-first storage model.
- No change to the fixed-user authentication model.
- No change to the rule that downloads must be streamed through PHP.
- The only practical change is routing discipline:
  - keep routing explicit and simple
  - treat rewrites as optional, not required
  - prefer deployment layouts that work on conservative Apache hosting

## Recommendation

For the MVP, deploy the app as a plain Apache PHP site with `public/` as the document root and no mandatory rewrite dependency. Add rewrite rules only later if the UI truly needs prettier URLs.