Caligrafy runs on ordinary PHP hosting, which means almost any shared plan or VPS with PHP, MySQL and Composer will serve it. There is no compiled extension, no special runtime and no exotic dependency. The harder question is not where to host Caligrafy but whether you should build something new on it at all, because it is a small teaching oriented framework with a tiny community, and the hosting decision should account for that.
composer create-project -s dev caligrafy/caligrafy-quill.Below is what Caligrafy actually requires, how to deploy it on both shared hosting and a VPS, the two configuration details that cause most first deploy failures, and an honest section on when a better supported framework is the smarter call.
What Caligrafy is, and what it is not
Caligrafy is an open source PHP MVC framework that pairs a small PHP backend with Vue.js on the front end. It ships a command line helper called caligrafer.php, a Docker setup, and a structure that will feel familiar to anyone who has used Laravel or CodeIgniter. It grew out of teaching material, and the current distribution lives in the caligrafy-quill repository.
Be clear eyed about scale. The repository has single digit stars and a handful of forks. That is not a criticism of the code, but it does tell you what to expect operationally: no packaged security advisories, few third party modules, almost no host specific documentation, and a real chance that you will be reading the source when something misbehaves. For a course project, a prototype or a personal site, that is fine. For a client application with a five year life, weigh it against the alternatives.
mcrypt, which was removed from PHP core in PHP 7.2 and now only exists as a PECL package. If a feature you use depends on it, you will need a host that lets you install PECL extensions, which shared hosting generally does not. Test the specific features you need before committing.Requirements and what a host has to provide
The documented baseline is PHP above 7.2 and MySQL above 5.6, with Git and Composer available, plus a set of common extensions. In practice you should target a modern PHP release rather than the minimum, because everything else in the ecosystem has moved on.
| Requirement | Documented minimum | What to actually run | Available on shared hosting? |
|---|---|---|---|
| PHP | Above 7.2 | 8.1 or newer | Yes, selectable in most panels |
| Database | MySQL above 5.6 | MySQL 8 or MariaDB 10.6 and up | Yes |
| Extensions | curl, mbstring, openssl, gd, bcmath, intl | Same, all standard | Usually yes, check intl |
| Composer | Required | Composer 2 | Only with SSH access |
| Document root control | Required | Point at the app entry folder | Yes on most cPanel hosts |
| URL rewriting | Required | mod_rewrite or Nginx try_files | Yes on Apache hosts |
Note the Composer row. It is the line that decides your hosting tier. If your plan has no SSH, you have to run composer install somewhere else and upload the vendor directory with the rest of the code, which works but makes updates tedious. Any host that gives you a shell removes that friction entirely.
Deploying Caligrafy on shared hosting
The shared hosting path assumes SSH is available. Create the database in the control panel first, then build the project in a directory outside the public web root and point the domain at the application folder.
ssh user@yourhost
cd ~
composer create-project -s dev caligrafy/caligrafy-quill myapp
cd myapp
cp .env.example .env
nano .env # set DB credentials and APP_ROOTThen set the domain’s document root to ~/myapp in the panel, or if your host insists on serving from public_html, symlink it. A symlink is cleaner than copying files because updates land in one place.
rm -rf ~/public_html
ln -s ~/myapp ~/public_html
ls -l ~ | grep public_htmlIf you cannot change the document root and the app has to live in a subdirectory, set APP_ROOT in .env to that subdirectory so generated URLs and asset paths resolve. Getting that value wrong is the single most common cause of a site that loads a blank page with broken CSS.
.env inside a directory the web server serves directly. If the file is fetchable over HTTP, your database credentials are public. Test it by requesting the path in a browser before you launch.Deploying Caligrafy on a VPS
A VPS is the better home for anything beyond a demo, and it costs about the same as a mid tier shared plan. Vultr and Linode start at $5 per month for 1 GB, DigitalOcean at $6. Install a LAMP or LEMP stack, deploy the code, and put a certificate in front of it.
sudo apt update
sudo apt install -y nginx mariadb-server php-fpm php-cli php-mysql \
php-curl php-mbstring php-gd php-bcmath php-intl php-xml git unzip composer
sudo mysql -e "CREATE DATABASE caligrafy CHARACTER SET utf8mb4;"
sudo mysql -e "CREATE USER 'cal'@'localhost' IDENTIFIED BY 'change-me';"
sudo mysql -e "GRANT ALL ON caligrafy.* TO 'cal'@'localhost'; FLUSH PRIVILEGES;"
cd /var/www
sudo composer create-project -s dev caligrafy/caligrafy-quill app
sudo chown -R www-data:www-data /var/www/appThe Nginx server block is the standard front controller pattern. Every request that does not match a real file goes to index.php.
server {
listen 80;
server_name app.example.com;
root /var/www/app;
index index.php;
location / {
try_files $uri $uri/ /index.php?$query_string;
}
location ~ \.php$ {
include snippets/fastcgi-php.conf;
fastcgi_pass unix:/run/php/php8.3-fpm.sock;
}
location ~ /\.env { deny all; }
}Finish with sudo certbot --nginx -d app.example.com for a Let’s Encrypt certificate. Caligrafy also ships a Docker setup, and running .bin/caligrafer server start gives you a working container without installing PHP on the host, which is a reasonable choice if you want the deployment reproducible. The same reasoning applies to other small PHP frameworks, as we cover in the guide to deploying FuelPHP on hosting.
composer.lock and deploy with composer install rather than composer update, so a surprise upstream change cannot break production on a Friday afternoon.When to pick a better supported framework instead
This is the part most hosting guides skip. Caligrafy is well suited to learning, to a course assignment, or to a small internal tool where you control every variable. It is a poor fit when any of the following is true: the application will outlive your involvement, you need a hiring pool that already knows the stack, you require a documented security response process, or you depend on third party packages for payments, auth or queues.
In those cases the sensible alternatives are Laravel for general applications, Symfony where you want strict architecture, CakePHP for a convention driven CRUD app, or Yii if you like scaffolding and active record. All four have larger ecosystems, published support timelines and hosting documentation everywhere. Our comparisons of where to deploy Yii and running CakePHP on cloud hosting walk through the same hosting decisions with far more community backing behind them. If raw speed is the driver, the extension based approach in our guide to publishing Phalcon on cloud hosting is another direction, though it comes with its own hosting constraints.
Troubleshooting a Caligrafy deployment
Blank page with a 500 in the log. Check the PHP error log first. Missing intl or bcmath is the usual cause on shared hosting, because those two are the least consistently enabled of the required extensions.
Page loads but every asset is 404. The APP_ROOT value in .env does not match where the app is served from. Set it to the subdirectory path, or empty it if the app sits at the domain root.
Routes other than the home page return 404. Rewriting is not active. On Apache confirm mod_rewrite is enabled and AllowOverride All is set. On Nginx add the try_files directive shown above and reload.
Composer fails with a memory limit error. Run it with the limit removed: php -d memory_limit=-1 $(which composer) install. On a 1 GB VPS, add swap first so the process is not killed outright.
Database connection refused after moving hosts. Many shared hosts prefix database and user names with your account name. Copy the exact strings from the control panel rather than reusing the local values in .env.
Frequently asked questions
Does Caligrafy need special hosting?
No. It is plain PHP with Composer dependencies, so it runs anywhere PHP and MySQL run. The only requirements beyond a basic plan are the ability to point the document root at the application folder and working URL rewriting, both of which are standard.
Can I install Caligrafy without SSH access?
Yes, but it is awkward. Run composer create-project on your own machine, then upload the whole tree including vendor over SFTP. Every dependency update repeats the process, which is why a plan with shell access is worth the small extra cost.
What PHP version should I run Caligrafy on?
The documented minimum is above PHP 7.2, but run 8.1 or newer. Older branches no longer receive security fixes, and most hosts have already removed them from the panel. Test your application on the target version before switching the live site.
Is Caligrafy actively maintained?
It is a small project with a correspondingly small amount of activity and a handful of contributors. Commits do land, but you should not expect the release cadence, advisory process or plugin ecosystem of a mainstream framework. Plan your support strategy accordingly.
Should I use Docker for Caligrafy?
If you are deploying more than once, yes. The project ships a Docker setup, and a container pins PHP version and extensions so the environment cannot drift. On a single small VPS a plain LEMP install is simpler, and either is defensible.
The bottom line
Caligrafy hosting is undemanding. Modern PHP, MySQL, Composer, a document root you can point where you want, and rewriting turned on. Shared hosting with SSH covers a demo or a class project, and a $5 to $6 VPS covers everything else with room to grow and a proper deployment workflow.
The real decision happens before hosting. Choose Caligrafy when the project is small, the scope is controlled and you value a compact codebase you can read end to end. Choose a mainstream framework when the application has to survive team turnover and years of security patching, because no amount of hosting quality compensates for a stack nobody else maintains.
