Deployment

Install from Packagist

A new app is one line — it pulls the skeleton + framework (tiger-core, tigerzf) and their deps, no clone, no build step:

composer create-project webtigers/tiger my-app

(A pre-built vendored ZIP + a browser web installer for no-shell / cPanel hosts is on the roadmap.)

Works on any web server

A zero-config public/.htaccess (front-controller routing) is the default — drop the app on Apache and it runs. Reference configs ship for an Apache vhost (the faster form), nginx, and Caddy/FrankenPHP. Asset URLs are root-relative and protocol-agnostic, so staging → prod moves and ALB/proxy setups just work.

Update-safe by construction

Framework code lives in vendor/ and is replaced by composer update; everything you own lives outside it. You never edit Tiger — you extend it (modules, config .ini overrides, subclasses). So an update can't clobber your work.

With a shell: composer update.
Without one: the one-click Updates screen — download → verify → apply → migrate, including a no-shell atomic core self-update. No FTP, no Composer.

Upgrading a pre-1.0 install to 1.x

Your app's composer.json is yours — the skeleton is copied once, so Tiger never edits it. An app created before 1.0 therefore still carries the old ceiling:

"webtigers/tiger-core": ">=0.1.0 <1.0.0"

That range excludes 1.x, and Composer doesn't treat it as an error — composer update just reports "Nothing to modify in lock file" and leaves you on 0.x. Widen it once:

"webtigers/tiger-core": "^1.0"

then composer update webtigers/tiger-core. (If the file also sets "minimum-stability": "beta", you can set it to "stable" now.) This is the one upgrade step that isn't automatic — precisely because that file is app-owned.

Shared hosting is a first-class target

Everything stays inside the account folder — no vhost edits, no system-tmp, no infrastructure a module install depends on. Tiger is built to run on cPanel/shared hosting, not just a VPS.