Hosting & CloudGlossaryPart 6 of 17
Deployment Glossary
31 terms from the Hosting & Cloud book's Deployment part, each defined in a line and linked to the chapter that explains it.
- Active CPU: a platform meter that accrues only while code is executing and pauses during I/O, so a function waiting on a database costs little (PaaS & Frontend Clouds).
- Blue/green deployment: running a new version beside the old and switching traffic at once; on platforms an immutable deployment with its own URL is a green environment that already exists, and promotion is the routing change (Platforms Take Over the Deploy).
- Build, release, run: the twelve-factor split that is a platform's data model: a build is the artifact from a commit, a release is that build plus a specific configuration, and run is processes started from a release (Platforms Take Over the Deploy).
- Buildpacks: the platform's way of turning source into a runnable artifact without a Dockerfile: detect the language, install the runtime and dependencies, compile and produce something the platform can start (Platforms Take Over the Deploy).
- Canary release: shifting a small share of traffic to a new version before the rest, sold by platforms as percentage traffic weights on slots, revisions or aliases (Platforms Take Over the Deploy).
- Capistrano: a deploy tool that scripts SSH to many servers to check out and build a release directory, link shared files and switch a symlink, so rollback moves the pointer (How Code Got to Servers).
- Classic PaaS: platforms such as Heroku, Render and App Engine standard that run processes from source in fixed sizes per month or hour, simple but priced well above the underlay (PaaS & Frontend Clouds).
- Frontend cloud: platforms such as Vercel, Netlify and Cloudflare Pages serving static assets, functions and previews on a CDN, billed by plan plus metered CPU, memory, requests and bandwidth (PaaS & Frontend Clouds).
- FTP: the original file upload protocol (RFC 959) over separate cleartext control and data connections, with cleartext credentials and partial uploads served live (How Code Got to Servers).
- FTP account (control panel): an additional login an account holder creates in the panel, confined to one directory, whose maximum number is a package limit (How Code Got to Servers).
- FTPS: FTP with TLS on both channels (RFC 4217), which fixed the cleartext password but kept the two-connection design that troubles firewalls (How Code Got to Servers).
- GitOps: the practice of keeping desired state in Git with an agent that pulls and reconciles it, so a deploy is a merged commit rather than a push from CI, and CI holds no production credentials (Platforms Take Over the Deploy).
- Hyperscaler PaaS: containers or code run on a cloud's own capacity (App Runner, Cloud Run, Azure App Service), with no reseller margin and the same bill and IAM as the rest of that cloud (PaaS & Frontend Clouds).
- Image push: a deploy where the customer builds an OCI image and the platform runs it, giving the same artifact everywhere while the customer owns base-image patching (Platforms Take Over the Deploy).
- Immutable deployment URL and alias: the model in which every deploy gets a unique, permanent URL and a stable domain is an alias pointing at one, so promotion, rollback and previews are alias moves (Platforms Take Over the Deploy).
- Invocations: a platform meter counting requests, alongside Active CPU and Provisioned Memory (PaaS & Frontend Clouds).
- Isolate platforms: platforms such as Cloudflare Workers that run code in V8 isolates everywhere, billed by requests and CPU time with runtime limits (PaaS & Frontend Clouds).
- Machine platforms: platforms such as Fly.io and Railway selling per-second VMs or containers with platform deploys, close to cloud prices with more operations left to the customer (PaaS & Frontend Clouds).
- Panel file manager: browser-based file operations inside a hosting account, needing no client but editing production directly, with the panel session as the credential (How Code Got to Servers).
- Preview deployment: a deployment of every pull request or non-production branch to its own URL, updated on each push and linked from the pull request, turning review into using the change (Platforms Take Over the Deploy).
- Procfile: a file in the repository naming an app's process types (
web,worker,clock) and the command for each, Heroku's process model (Platforms Take Over the Deploy). - Provisioned Memory: a platform meter that accrues GB-hours for an instance's lifetime until its last in-flight request finishes (PaaS & Frontend Clouds).
- Release directory: the deploy pattern of building each release in a new directory and switching a pointer to it, which made a deploy atomic and rollback instant, unlike copying into the served directory (How Code Got to Servers).
- rsync: a delta-transfer tool over SSH or its own daemon that moves only changed blocks, cheap for mirroring a release to many servers but updating in place unless paired with release directories (How Code Got to Servers).
- Scripted push from CI: a pipeline that runs deploy commands with production credentials, working anywhere but making CI a production credential holder (Platforms Take Over the Deploy).
- SFTP: the SSH File Transfer Protocol, file transfer inside one SSH channel with one port and key authentication, chrootable but never an RFC and still not atomic (How Code Got to Servers).
- Slots and revisions: named or numbered versions of an app with traffic weights (Azure App Service slots, Cloud Run revisions, Lambda aliases), giving percentage canaries inside one product (Platforms Take Over the Deploy).
- Source push: a deploy where the platform detects, builds and runs the customer's source with buildpacks, needing no build configuration but with opaque builds (Platforms Take Over the Deploy).
- Spend cap: a platform's limit on metered spend with an explicit action at the threshold (notify, pause production, pause everything); platform caps pause the customer's site, the opposite of a hyperscaler's alert-only default (PaaS & Frontend Clouds).
- Spin-down: a free tier's practice of stopping a service after a period without inbound traffic, because the platform pays for warm capacity (PaaS & Frontend Clouds).
- Twelve-Factor App: Heroku's written contract for apps (one codebase, declared dependencies, config in the environment, backing services as resources, separate build, release and run, stateless processes and more), whose factor five is a platform's data model (Platforms Take Over the Deploy).