Portfolio hosting

One visitor matters more than the other thousand: the one deciding whether to hire.

A portfolio shows the work and wins the next job. Sometimes it belongs to the person who made the work — a photographer, illustrator, audio engineer, developer. Just as often a freelancer or agency builds it for a creative client and keeps it in the same account as the rest of their work. Either way the shape is the same: a body of work a stranger can take in quickly, and a way to make contact.

# Very little logic, a great deal of media

PHP renders a handful of templates and stops; the weight is in the media. Every environment books storage as a required component — a persistent file system with SSH and SFTP access, so uploads survive deploys instead of living inside a build. Media committed to the repository ships with each git push, which suits a site that changes twice a year.

# Quiet for months, then vertical for two days

A portfolio gets a trickle until a project is picked up somewhere. Almost all of that traffic is anonymous reads, so the CMS's page cache absorbs most of it before PHP does real work — and the PHP component can be scaled up for a few days and back down, each day billed at 1/30th of the monthly rate.

Months pass between updates, which is its own risk: the software goes unpatched as long as nobody touches it. A flat-file CMS keeps content in the repository, so there is no database component to book and the whole site restores from a Git clone plus one rsync of the uploads.

# Why fortrabbit?

Because we ran a web agency before we ran a hosting company, and the portfolio was always the same job: no budget, no traffic, and more riding on it than anything else in the account. A flat-file build that ships with the repository, storage that survives every deploy, and per-day billing that stays near the floor between bursts. When it is client work, ownership hands over without the site changing address — an administrative act, not a migration.