Installation

Composer

The recommended install path is Composer. Require the package in your TYPO3 project (also on Packagist and TER):

composer require codemacher/t3vault

T3Vault depends on codemacher/elephstamp (OpenTimestamps), which is pulled in automatically from Packagist.

Provisioning of <web-dir>/t3vault runs via typo3/cms-composer-installers (InstallerScripts) on composer install / update / dump-autoload.

Standalone app provisioning

On every composer install / update / dump-autoload, T3Vault copies the standalone app into <web-dir>/t3vault.

The configuration (<project>/var/t3vault/config.local.php and backup.password.php, outside the web root) is never overwritten; legacy copies inside <web-dir>/t3vault/ are migrated automatically.
Opening the T3Vault backend module also re-syncs that folder as a fallback.

After composer remove codemacher/t3vault, delete the leftover web copy manually if it is still present:

rm -rf public/t3vault

Activation

Activate the extension in the Extension Manager / Package Manager (Composer installs usually activate automatically).
Open Admin Tools → T3Vault (module path /module/tools/t3vault; admin users only).
Set the standalone password when prompted (used for disaster recovery login outside the TYPO3 backend).
In the T3Vault UI settings, set a backup encryption password (minimum 8 characters) before creating the first backup.

Important

Store the backup encryption password offline. Without it, encrypted ZIP parts cannot be restored. AES-ZIP does not hide file names or the directory tree — keep backups outside the web root.

Web root hardening

The standalone app is provisioned into the public web root (<web-dir>/t3vault). The configuration with all secrets lives outside the web root (<project>/var/t3vault/, see Configuration), and so does the ENABLE_T3VAULT marker (see Enable marker); the app directory still ships an Apache .htaccess that protects legacy config.local.php copies, legacy marker files, the installer templates (*.tpl) and any backup artifacts, and restricts the Api/ directory to Api/index.php.

Warning

.htaccess files are ignored by nginx and Caddy. On those web servers you MUST replicate the rules in the server configuration, otherwise legacy config.local.php copies, the installer templates and backup files become publicly downloadable.

nginx equivalent (place inside the relevant server block):

location ^~ /t3vault/ {
    # Protect legacy configuration/marker copies inside the web root.
    location ~ ^/t3vault/(config\.local\.php|ENABLE_T3VAULT)$ { deny all; }

    # The Api/ directory only exposes index.php – everything else
    # (framework classes, installer templates) is read from disk by PHP.
    location ~ ^/t3vault/Api/(?!index\.php)  { deny all; }

    # Never serve templates, logs, PHARs or backup artifacts as static files.
    location ~ ^/t3vault/.*\.(tpl|log|sql|gz|zip|tar|phar)$ { deny all; }

    # Security headers for the SPA shell (T3V-022). frame-ancestors does NOT
    # fall back to default-src and must be set explicitly; 'self' allows the
    # same-origin TYPO3 backend iframe. script-src is 'self' only (the shell
    # loads bootstrap.js instead of an inline block); style-src keeps
    # 'unsafe-inline' for MUI/Emotion's runtime styles.
    add_header Content-Security-Policy "default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data:; connect-src 'self'; font-src 'self' data:; object-src 'none'; base-uri 'none'; frame-ancestors 'self'" always;
    add_header Referrer-Policy "no-referrer" always;
    add_header X-Content-Type-Options "nosniff" always;
}

For classic installations (project root equals the document root) the private runtime directory var/t3vault/ (configuration, secrets, state) is web-reachable and must be denied as well:

location ^~ /var/t3vault/ { deny all; }

Additionally protect the backup target directory. The default (<project-root>/var/t3vault/backups) already lives outside public/; if you override backupBaseDir, keep it outside the web root.