Forge's zero-downtime deploy is a symlink swap, and nothing more exotic than that. Each deploy clones the repository into a timestamped directory under `releases/`, runs your deployment script inside it, then repoints the `current` symlink [10]. Forge keeps the last four releases for instant rollback [11], which leaves three older ones to fall back to once you count the release you are running [16]. That is the whole rollback story. It is a good one, because it fails in ways you can inspect with `ls`.
The failure mode is state. `.env` and `storage` have to be listed as shared paths in the site's zero-downtime settings, or each release ships with an empty storage directory: uploaded files vanish and sessions break [13]. The sample script also ends with `php artisan migrate --force`, and `--force` exists precisely to bypass the production confirmation prompt [12]. The prompt you are skipping is the one that would have asked whether you meant it.
Cloud runs that same list on your behalf. According to the dev.to comparison, it executes `composer install --no-dev`, the config, route and view caches, and migrations on every deploy, provisions a preview environment per branch, scales replicas with traffic, rotates SSL certificates and holds encrypted environment variables [4]. The first invoice for that is architectural rather than monetary: no SSH to the instance, no PHP extension outside the platform image, no direct Nginx configuration, and no long-lived daemon outside the provided worker abstraction [5].
The serverful framing is the part to read slowly. Cloud runs on Amazon EC2 and keeps the container warm between requests, so there are no Lambda cold starts [2][3]. That is a claim about the platform's architecture rather than about your p99. It transfers only if cold starts were on your list to begin with, which means bursty or low-volume traffic against a runtime that scales to zero. If your app already sits behind a permanently provisioned PHP-FPM pool on a Hetzner box that Forge configured for you [8], warm containers return something you already had.
Then the money. Starter carries no monthly subscription and bills only compute and bandwidth consumed, while Growth starts at $20/month with higher resource ceilings [6]. That floor is $240 a year [17] before a single request is metered, and the source is candid that usage billing is predictable under steady traffic and can spike with bursts [7]. Against a fixed-size server, you are buying elasticity and paying for it exactly when traffic is worst.
My read is that the exclusion list decides this, not the team's appetite for ops. If you need PostgreSQL 18, which Forge now supports for new deployments, or multiple queue worker groups, or one specific extension, Cloud is out and the only remaining question is whether Forge's DigitalOcean-backed Laravel VPS, with root and SSH and consolidated billing, beats building Ubuntu yourself [15][9]. If nobody on the team owns servers, the automation is cheaper than the hire. The wrong pick, as the guide puts it, costs money or engineering time or both [1], and the second cost is the one that does not show up on a pricing page.
