№ 01 Glossary
The back of the manual.
Every jargon word this site uses, defined in plain English — and who actually deals with it once it's running: us, you, or both.
64 of 134terms on this page are things you never have to touch.
№ 02 Delivery & network
From visitor to server
How a request actually gets to a server, and back.
- CDN (edge network)also: Content delivery network, global edge network, edge network
- A network of servers positioned close to visitors around the world, so a page loads from whichever one is nearest instead of one far-away server.
- Static files — HTML, images, scripts — get cached at points around the globe, so a visitor on the other side of the planet from wherever a site is hosted still gets it fast. It is the layer that makes a site feel quick everywhere, not just near its origin.
- See also: Origin, Cache purge, Latency
- Origin
- The one real server behind the edge network — where a request goes when nothing cached can answer it.
- Everything the edge network serves ultimately came from somewhere; the origin is that somewhere. For a static site it is durable storage holding the built files; for a dedicated instance it is the instance itself, sitting behind the edge and TLS termination.
- See also: CDN (edge network), Dedicated instance
- Latency
- How long a request takes to get an answer back, measured in milliseconds — the thing an edge network exists to shrink.
- Distance to the nearest server is the biggest lever on it, which is what an edge network is for. A visitor’s own connection plays a part too, which is why this is one of the few rows on this page marked Shared rather than a clean CustomHosted.
- See also: CDN (edge network)
- Egressalso: bandwidth, data transfer
- Data leaving our network on its way to a visitor — the traffic a usage-based host would meter and bill for.
- Every page view, image, and API response sends data out; some hosts charge per gigabyte for exactly that. It is folded into the flat rate here, which is the honest reason "no bandwidth surprises" is a real claim and not a slogan.
- See also: Flat-rate pricing, Usage-based pricing
- Cache purge
- Telling the edge network to drop a stale copy of a file so the next visitor gets the current version.
- A deploy that changes a file the edge network already cached needs this step, or some visitors keep seeing the old version until the cache expires on its own. It runs automatically on every deploy here, not as a manual button someone has to remember to press.
- See also: CDN (edge network), Redirect (301/302)
- Static asset
- A file that is the same for every visitor — HTML, CSS, an image, a font — as opposed to a page a server builds fresh per request.
- Static assets are what an edge network is built to serve directly, without touching a server at all. A whole site made only of these is what a Static Starter plan hosts; anything that computes a response per request needs a dedicated instance behind it instead.
- See also: Static site, CDN (edge network)
- Redirect (301/302)also: 301, 302, permanent redirect, temporary redirect
- An instruction that sends a visitor — and a search engine — from one address to another instead of a page.
- A 301 says the move is permanent, so a search engine updates what it has indexed; a 302 says it is temporary, so the original address stays the one that counts. Getting this choice right is most of what keeps search rankings intact through a move.
- See also: Cache purge
- Security headeralso: response header, HSTS, security headers policy
- An instruction sent alongside a page that tells a browser to switch on a specific protection, rather than code the page itself has to run.
- Headers like these tell a browser to always use the secure address, not to guess a file's type, and not to let another site frame your page — all on by default here. A Content-Security-Policy is the one header in the set that is a choice rather than a default, because a wrong one can break a working page.
- See also: Redirect (301/302)
- SPA fallbackalso: deep-link fallback, catch-all route
- A rule that serves a single-page app's own starting page for any address its own router handles, instead of a 404.
- A single-page app draws most of its own pages in the browser, so a direct link to one of them has no matching file for the edge network to serve on its own. This rule is what makes that direct link work — checked against the app's own routes, not guessed at from outside.
- See also: Static site
- Not-found page (404)also: 404 page, page not found
- The page a visitor gets for an address that genuinely does not exist, with a real 404 status code attached.
- It is a file in your own repository, not a generic error document from somewhere else in the stack. Writing or changing it is a briefed change like any other.
- See also: Maintenance page, Error page (5xx)
- Maintenance pagealso: maintenance window, holding page, coming soon page
- A "we'll be back" page swapped in for the length of a planned change, then swapped back out.
- Asking for one is an ops request, not a metered feature — the real site returns once the change behind it is done and confirmed working.
- See also: Not-found page (404), Error page (5xx)
- Error page (5xx)also: 500 error, 502, 503, 504, bad gateway
- The page shown when your app is up but answering wrong, rather than a page that simply does not exist.
- It is your own page, written for the case where a dependency fails or the app itself has a bug. A dedicated instance that is not answering at all has nothing left to serve it with.
- See also: Not-found page (404), Maintenance page
- Measurement tagalso: analytics tag, tracking pixel, analytics snippet
- A snippet a visitor-analytics tool adds to a page so it can count a visit — a tool you choose, not one the platform runs for you.
- The platform hosts the page a tag sits on; it does not add or run the tag itself. Adding one is a briefed change like any other, reviewed against the same allowlist this site holds its own single tag to.
- See also: Page view, Cookie
- Page viewalso: pageview, visit, session
- One visitor loading one page — the unit a visitor-analytics tool counts up into traffic figures.
- This platform doesn't record page views on its own — that count comes from whichever measurement tag you add. What the platform does meter on every plan is the transfer a page view costs in bytes, against the fair-use allowance on the rate card.
- See also: Measurement tag
- A small value a browser stores and sends back on later requests — how a tool tells one visitor's repeat visits apart from another's.
- The platform itself sets no cookie of its own. A measurement tag you add may set one to do its job, and disclosing that is yours to make — see Analytics for the platform-versus-tool split, and Privacy for the binding wording on the one tag this site discloses.
- See also: Measurement tag
- Lab vs. field measurementalso: real user monitoring, synthetic monitoring
- A lab number comes from measuring a build by itself; a field number comes from a real visitor's own device and connection.
- Performance publishes a lab number — bytes measured from this site's own build, the same every time it runs. A field number needs real visitor traffic behind a measurement tool instead, which is why it's named as an honest gap rather than invented.
- See also: Measurement tag
- Canonical URL
- The one web address a page names as its own — the address a search engine keeps, when more than one URL could show the same content.
- Every page here states its own canonical address in its own markup. That keeps a search engine from splitting one page's ranking across two addresses it never meant to be separate.
- See also: Redirect (301/302), Sitemap
- Sitemap
- A machine-readable list of every page on a site, so a crawler can find one without following every link by hand.
- This site's sitemap regenerates on every deploy, so it never falls out of step with what actually got published. A robots file names where to find it.
- See also: Crawler, Canonical URL
- Structured dataalso: schema, JSON-LD, rich results
- Markup added to a page that states a fact in a form a machine reader can parse directly, instead of inferring it from prose.
- This site marks up who runs it, what it offers, its breadcrumb trail, and its own questions and answers — so a search result or an answer engine can quote them directly rather than guessing from the page text.
- See also: Sitemap
- Crawleralso: bot, spider
- A program that fetches pages the way a browser does, then follows their links, to build up an index of what a site contains.
- A search engine or an answer engine each run their own crawler. What one meets when it fetches a page — real HTML, or a blank shell waiting on a script — depends on the hosting shape underneath it.
- See also: Sitemap, Structured data
- Client-side validation
- A form check that runs in the visitor's own browser, before a submission is sent.
- It stops a normal visitor from submitting a blank required field. It does not stop a script that posts straight to the endpoint — that check has to run again on the server side. See Forms for the full rule.
- See also: Form endpoint, Honeypot field
№ 03 Compute & storage
Where your app actually lives
The two shapes almost everything we host reduces to, plus the pieces underneath them.
- Static site
- A site built once into plain files and served as-is — no server computing a response per visitor.
- You (or CustomLabs) build it; the built files are what gets hosted, not a running application. It is the cheapest shape there is precisely because nothing has to run continuously to serve it — no process to patch, restart, or size.
- See also: Static asset, Dedicated instance
- Dedicated instancealso: dedicated server, dedicated compute
- A fixed slice of compute — CPU, memory, a static IP — that runs your app continuously, not shared unpredictably with anyone else’s traffic.
- This is the shape for anything with a server-rendered route, an API, or a background process: WordPress, Django, a Next.js app with API routes, a Docker container. It is sized to the workload and billed at one flat rate rather than metered by the request.
- See also: Process manager, Static site
- Managed databasealso: managed Postgres, hosted database
- A database CustomHosted provisions, patches, backs up, and watches for you, sized into one of a few fixed tiers.
- Standalone, or attached to a Static or Dedicated plan — either way, the backups, the patching, and the watching are ours. Writing a schema change, and reaching it from your app, stay yours.
- See also: Schema migration, Connection pool, Dedicated instance
- Containeralso: Docker container
- An app packaged with everything it needs to run, so it behaves the same wherever it is deployed.
- A single container runs on a dedicated instance the same as any other app; several containers wired together (a Compose stack) get designed and quoted flat instead of squeezed into one tier. You bring the image or the Dockerfile — we run it, not re-package it.
- See also: Dedicated instance
- Process manager
- The thing on a dedicated instance that keeps your app’s process running, restarting it automatically if it crashes or on every deploy.
- Without one, a crashed app just stays down until someone notices. It is already wired up on every dedicated instance here, so a bad request or an unhandled error does not turn into an outage that waits for a human to spot it.
- See also: Dedicated instance, Health check
- Build artifact
- The output of a build step — the actual files or image that get deployed, as opposed to the source code that produced them.
- A push to main runs the build — `next build`, a Composer install, a Docker image build — and the artifact it produces is what actually goes live. Deploys here trigger on the same push you would make anyway; there is no separate build server to babysit.
- See also: Static site, CI, Deploy
- Object storagealso: durable storage, blob storage
- Durable storage for files — a built static site, an uploaded image, a backup — that is not tied to any one running server.
- It is what a static site’s built files live in, what an uploads directory backs up to, and what survives even if the compute in front of it gets replaced. Replicated across multiple facilities, so one hardware failure does not touch what is stored there.
- See also: Backup, Static site, Uploads directory
- Background workeralso: queue worker, job runner
- A process that runs jobs — sending emails, generating a report, working a queue — with no browser ever waiting on it directly.
- Celery, RQ, a scheduled cron job, a Laravel queue worker — all the same shape underneath: something that has to keep running even though no one is looking at it in the moment. It is sized and billed as its own line item, not assumed to be free because "the web server probably covers it."
- See also: Process manager, Queue, Scheduled job (cron)
- Queuealso: job queue, queue worker
- A waiting line for jobs, so a background worker takes each one in turn instead of dropping work that arrives faster than it can run.
- A request that triggers a job hands the work off to a queue and returns at once — the worker behind it picks jobs up one at a time, on its own schedule, not the visitor's.
- See also: Background worker, Scheduled job (cron)
- Scheduled job (cron)also: cron job, cron, nightly job
- A job that runs on a clock instead of a request — once a night, once an hour, on a fixed timetable.
- Wired in as part of provisioning on day one, not left as a manual step to remember. Every scheduled job on this platform runs on the same clock, stated in full on the page it links to.
- See also: Background worker, Idempotency
- Idempotencyalso: idempotent, run twice, safe to retry
- Whether running the same job twice does the same thing as running it once, instead of double-charging a card or sending a second email.
- A retried job can run more than once — this platform is at-least-once, not exactly-once. Whether a second run is safe is decided in the job's own code, not something hosting can guarantee from underneath it.
- See also: Scheduled job (cron), Background worker
- Vertical resizealso: resize, move up a tier, scale up
- Moving a workload to a bigger (or smaller) tier of the same shape — more CPU and memory on the same instance, not a different architecture.
- Static tier changes and dedicated resizes on this platform are both this: the same instance shape, more or less of it. It is the opposite of splitting a workload across more than one instance, which this platform deliberately does not offer as a setting.
- See also: Dedicated instance, Headroom
- Headroom
- The gap between what a workload is actually using and the limit of its current tier — disk, memory, or connections still spare.
- Watching headroom, not waiting for it to run out, is what turns a resize into a scheduled move instead of an outage. It is flagged well ahead of the point it would actually cause a problem.
- See also: Vertical resize, Autoscaling
- Autoscalingalso: auto-scaling, scaling group
- Compute or storage that grows and shrinks on its own, without anyone asking for it — a capability this platform deliberately does not offer.
- A flat rate means fixed, known capacity: nothing here grows itself in the background and bills you for it afterwards. A resize is always something you ask for, or something we flag and you decide on — never a silent, automatic step.
- See also: Vertical resize, Headroom
- Concurrencyalso: concurrent users, concurrent requests
- How many requests a workload answers at the same moment, as opposed to how many it answers over a whole month.
- A tier that easily handles a steady trickle of visitors can still struggle if a few hundred of them arrive in the same second. Concurrency, not total traffic, is what a rehearsal actually measures.
- See also: Load test, Knee
- Load testalso: stress test, benchmark
- A rehearsal that sends a rising amount of traffic at a standing copy of an app to find out where it starts to strain.
- Run against staging, never production, so the rehearsal itself never becomes the incident it is trying to prevent. It answers "how much can this actually hold" with a real number instead of a guess.
- See also: Concurrency, Knee
- Kneealso: saturation point
- The point on a graph where a workload stops answering normally and starts queueing, slowing, or failing.
- Below the knee, more traffic looks the same as less. Above it, response times climb and errors start appearing — a load test finds exactly where that point sits for a given workload and tier.
- See also: Load test, Headroom
- Uploads directoryalso: uploads folder, media folder, user uploads
- The folder on an app's own disk where a visitor's upload lands — not in git, and not rebuilt by a deploy.
- It exists only because a visitor made it. A deploy never touches it; a nightly backup does — see Files for what actually lands there, and Recovery for how it comes back.
- See also: Object storage, Persistent disk, Ephemeral filesystem
- Persistent diskalso: instance disk, local disk
- The disk attached to a dedicated instance — it survives a restart and a resize, sized into the tier it runs on.
- It is where an uploads directory and a cache actually live on a dedicated plan. It moves with a resize, and it does not exist at all on a static plan — the reason a static site can never accept an upload directly.
- See also: Dedicated instance, Uploads directory, Ephemeral filesystem
- Ephemeral filesystemalso: ephemeral disk, ephemeral storage
- Disk space that resets on every restart or redeploy — the wrong place to keep a file you need back.
- A cache or a temp file belongs here. An upload does not, unless your app also writes it somewhere durable before the process cycles. Files draws this line in full.
- See also: Persistent disk, Object storage
- Form endpointalso: form handler, contact form backend
- A small managed endpoint that catches a form submission — the one thing a static site needs briefed in to receive anything at all.
- A static plan has no server standing by to catch a POST request. A briefed endpoint fills that one gap, then runs on its own — see Forms for where a submission goes from there.
- See also: Static site, Honeypot field
- Content change
- A word, a picture, or a whole new page — the three things people ask to change on a site after launch.
- On a static build, none of the three is a click in a dashboard. Each one ships as a briefed pull request, the same as any other change to the code.
- See also: Headless CMS, Brief
- Headless CMSalso: headless content
- A service that holds your content and hands it to your site over its own API, instead of a database or a file in the repository.
- Your build or your app fetches a word or a picture from that outside service at the point it is needed. It is one of three places content actually lives — see the other two on Content.
- See also: Content change, Third-party service
- Alt textalso: alternative text, image alt attribute
- The words a screen reader speaks in place of a picture — written once, alongside the picture itself.
- Swapping a picture without swapping its alt text leaves a screen reader describing the old one. Briefing the two together is what keeps them matched.
- See also: Content change, Lazy loading
- Lazy loadingalso: loading="lazy"
- Telling the browser to fetch a picture only once a visitor scrolls near it, instead of on first paint.
- A picture far down the page does not need to load before the visible part of the page does. Marking it lazy defers the fetch, and the one above the fold stays out of that rule so it still loads first.
- See also: Alt text, Layout shift
- Responsive images
- Serving a picture sized to the space it fills, rather than one large file every visitor downloads in full.
- A photo shown at 400 pixels wide does not need to ship at 4000. Briefing the sizes a design actually uses is what keeps a picture from costing more than its own space on the page.
- See also: Lazy loading
- Layout shift
- The page jumping as a picture finishes loading, because nothing reserved its space in advance.
- A picture with no declared width and height gives the browser nothing to reserve space with, so the text around it jumps once the picture arrives. Declaring both stops the jump.
- See also: Lazy loading
№ 04 Domains & certificates
The name, and proving it’s yours
Getting a domain name to actually resolve to your site, safely.
- DNSalso: Domain Name System
- The system that turns a domain name into the address a browser actually connects to.
- Every request starts here: a visitor types a domain, DNS resolves it to the edge network, and the request proceeds from there. Records get kept correct as services and subdomains change — one of the maintenance items that quietly falls off most teams’ radar until it breaks.
- See also: DNS record, Nameserver
- DNS recordalso: A record, CNAME record
- A single entry in DNS — an A record pointing a domain at an address, a CNAME pointing one name at another, and so on.
- Adding a subdomain, verifying a mail provider, or pointing a domain here in the first place all come down to changing one of these. They are managed end to end once a domain is here, rather than left as a spreadsheet only one person remembers how to edit.
- See also: DNS, Nameserver
- TLS certificatealso: SSL certificate, HTTPS certificate
- The credential that lets a browser confirm a site is really who it says it is, and encrypts the connection to it.
- Issued and renewed automatically here, months ahead of expiry — no calendar reminder, no expired-certificate outage at 2am. Every property gets one by default; there is no plaintext hop anywhere in the path.
- See also: HTTPS redirect, DNS
- Domain registrar
- The company you actually bought the domain name from — a separate thing from whoever hosts the site it points to.
- This one honestly stays yours: the registration itself, and its renewal, is between you and whoever you registered it with. What we manage is everything downstream of it — the DNS records and TLS certificate that make the domain actually work once it is pointed here.
- See also: Nameserver, DNS
- Nameserver
- The setting at your domain registrar that tells the internet whose DNS to trust for your domain.
- Pointing a domain’s nameservers here is usually the one setting you change yourself — after that, every record underneath it is managed end to end. It is a five-minute change at the registrar, not a migration.
- See also: DNS, Domain registrar
- HTTPS redirect
- Automatically sending anyone who types the plain http:// address to the secure https:// one instead.
- Without this, an old link or a typed-in address can land a visitor on an unencrypted page even though a certificate exists. It is on by default here, so there is no unencrypted version of a page actually reachable.
- See also: TLS certificate
- SPFalso: Sender Policy Framework
- A DNS record naming which mail systems are allowed to send as your domain.
- A domain can only carry one SPF record — adding a second one breaks the first, rather than adding to it. Sending as your own domain through a mail relay means that relay's entry gets merged into whatever record you already have.
- See also: DKIM, DMARC
- DKIMalso: signing record
- A signature added to outgoing mail that lets a receiving server confirm it really came from your domain's own key.
- Added as a small set of DNS records — this platform uses three — that sit alongside your existing records without touching any of them.
- See also: SPF, DMARC
- DMARC
- A DNS record telling a receiving server what to do with mail that fails the SPF or DKIM checks.
- Optional here, and started in report-only mode — it collects data on failures without rejecting anything, so nothing about your existing mail changes the day it is added.
- See also: SPF, DKIM
- Mail relay
- An authenticated service an app sends mail through, instead of calling a mail server directly.
- A machine's own direct outbound mail port is closed on this class of infrastructure and stays closed — an app calls an authenticated relay on a submission port instead, with credentials wired in the same way any other secret is.
- See also: Transactional email, Secrets management
- Transactional email
- Mail triggered by one person's own action — a password reset, a receipt, an invitation — as opposed to bulk or marketing mail.
- This is the mail almost every real app sends. It is the kind of sending this platform supports; a newsletter or a mass campaign sent to a list is not.
- See also: Mail relay, Bounce
- Bounce
- A message that a receiving server refuses or fails to deliver, reported back to the sender.
- A hard bounce means the address itself is bad and no retry will fix it; a temporary deferral is the receiving side asking to try again later. Which one happened decides whether the fix is your data or just a wait.
- See also: Transactional email
№ 05 Reliability & recovery
When something breaks
What happens when something breaks, and how fast it stops mattering.
- Uptime
- The share of time a site or app is actually reachable and working, usually quoted as a percentage.
- "Eleven nines" durability and a stated uptime figure are different claims about different things — durability is about data surviving, uptime is about the thing being reachable right now. It is watched continuously here, not checked when someone happens to notice a problem.
- See also: SLA, Incident, Health check
- SLAalso: Service-level agreement
- A written commitment about uptime and response time, with a real consequence if it is missed.
- It is the difference between a marketing claim and something you can point to. The commitment here is in writing, not a number on a page that quietly means nothing if it is missed.
- See also: Uptime, Incident
- Backup
- A copy of your data and files, taken on a schedule, that a restore can be pulled from if something goes wrong.
- Taken nightly here without a script anyone has to remember to run — and for a site with an uploads directory, the files and the database back up together, so a restore is one operation instead of a database dump plus a media folder you hope you saved.
- See also: Point-in-time recovery, Object storage
- Point-in-time recoveryalso: PITR
- Restoring a database to exactly how it looked at a specific moment, not just to last night’s backup.
- Useful when the problem was a bad migration or a bad write a few hours ago, not an outage overnight — a nightly backup alone cannot get you back to 2:14pm yesterday, but this can. It is what the managed database tiers back up with, alongside the nightly copy.
- See also: Backup
- Connection poolalso: connection limit, pool limit
- A small set of open connections an app reuses, instead of opening and closing a new one for every query — and the thing that has a limit.
- Faster than opening a fresh connection each time, and the reason a tier caps how many it will hold open at once. Running near that cap for more than a brief spike is the signal to move up a tier, or to fix a connection leak in the app.
- See also: Managed database, Connection string, Headroom
- Rollback
- Reverting a deploy back to the previous working version, fast, when a new one turns out to be broken.
- The safety net behind every cutover and every deploy: if something looks wrong right after it ships, going back to the last known-good version is a rehearsed step, not an improvised one. It is the reason "little-to-no downtime" can be said about a migration with a straight face.
- See also: Staging environment, Incident
- Incident
- A real, ongoing problem affecting a site or app — as opposed to a blip nobody but a monitor noticed.
- Logged, worked, and closed with a written note rather than handled quietly and forgotten — the first hour, how you hear about it, and what it costs are laid out in full on the page this term links to.
- See also: Uptime, SLA, Break-glass access
- Outage
- The site or a core function down, or badly degraded, for real users — the top tier of an incident.
- Worked ahead of the routine queue, with priority handling — see the escalation ladder for the other two tiers, and how each one is handled.
- See also: Incident, Escalation
- Service credit
- A credit toward a future invoice, issued when monthly uptime falls short of the SLA target.
- Grows in steps as uptime falls further below target, on a published ladder — never paid out as cash, always applied to a future invoice.
- See also: SLA, Incident
- Escalation
- The path an incident takes from a first automated signal to the humans who decide what to do about it.
- Most of what fires never reaches a person at all — the ladder decides what gets fixed automatically, what reaches you in writing, and what gets worked as an outage.
- See also: Incident, Outage
- Health checkalso: monitoring
- An automatic, repeated check that a running app is actually responding correctly, not just that the server is technically on.
- A server can be up while the app on it has silently crashed or hung; a health check is what catches that gap and restarts the process before a visitor hits a dead page. It runs continuously here, watching both uptime and error rate.
- See also: Process manager, Uptime
- Request log
- A line written automatically for every request at the edge — who asked for what, and what the answer was.
- Written before your own code ever runs, so it exists even for a request your app never got the chance to handle. Kept for a set window, then aged out — see Logs for how long.
- See also: Application log, Retention window, Incident
- Application logalso: app log, application output
- A line your own code chose to write down — a caught error, a warning, a debug message.
- Only exists if your code writes it. It is the record that says what your app decided to do with a request, once the request log has already narrowed down which one to look at.
- See also: Request log, Incident
- Retention window
- How long a record is kept before it ages out on its own — a window, not a permanent archive.
- Every record class here — a request log, an application's own output, a change record — ages out on its own schedule rather than being kept forever.
- See also: Request log, Backup
- Source-code escrow
- A copy of the source code held by a neutral third party, released to a customer only if the vendor fails — something this platform does not offer.
- Escrow exists to solve a problem this platform doesn't have: you already hold the repository yourself, with its full history, while you're a customer. There is nothing else to lock away for later release.
- See also: Key-person risk
- Key-person riskalso: bus factor, single person
- The risk that a service depends on one specific person, so their absence stops the work.
- The question a cautious buyer asks about a small provider: what happens if the one person who knows the stack is away, or gone. The honest answer here is what runs on its own, what waits for a person, and what you already hold either way.
- See also: Source-code escrow, Runbook
- Runbook
- A written document saying what each piece of a stack is and how it fits together, for whoever picks it up next.
- Part of the handover pack, and the plainest answer to key-person risk on paper: it doesn't depend on asking the right person the right question, because the answer is already written down.
- See also: Key-person risk
№ 06 Security
What nobody budgets time for
The unglamorous list that a managed host exists to take off your plate.
- Patching
- Keeping the operating system and runtime a site or app runs on updated against known security vulnerabilities.
- This is the maintenance-list item most likely to get postponed when there is no one whose job it explicitly is. Security patches apply on a schedule here; anything that could break the app first goes through the same reviewed-change process as any other update.
- See also: Firewall
- Firewall
- A layer that only lets through the network traffic a server is actually supposed to receive, blocking the rest by default.
- Every dedicated instance sits behind one configured to the ports the app actually needs — not left wide open because no one got around to locking it down after launch.
- See also: DDoS mitigation
- Secrets management
- Keeping API keys, passwords, and tokens out of source code and injected in at runtime instead.
- A secret baked into a Dockerfile or committed to a repo is a security problem waiting to be found — including by CodeHerder’s own agents reading the codebase to make a change. The values are yours; where they are stored and how they reach the running app is handled here.
- See also: Environment variable, Principle of least privilege, Break-glass access
- Connection stringalso: database URL, DSN
- The one secret an app holds to reach its database — address, credentials, and database name in a single value.
- Kept the way any other secret is, never written into the code itself — see how a secret is actually stored. The value is yours; where it lives and how it reaches the running app is handled here.
- See also: Secrets management, Managed database, Connection pool
- Environment variablealso: env var
- A named value an app reads from the environment it runs in, instead of from a line written into its own code.
- The same mechanism holds a plain setting and a secret alike — the difference is what the value is, not how it arrives. Your code reads it by name at startup, the same way on every hosting shape.
- See also: Configuration, Build-time value, Secrets management
- Configuration
- The settings, environment variables, and secrets an app reads at startup — as distinct from the code itself.
- Two different things share the word here: a setting anyone could see, and a secret that must not leak. Where each one lives, and who can read it back, is answered in full on this term's own page.
- See also: Environment variable, Build-time value, Config drift
- Build-time value
- A configuration value read in while a static site or app is being built, not while it is running.
- Baked into the files a browser downloads, which makes it public the moment it ships — never the right place for a secret. A run-time value on a standing process is the safer home for one.
- See also: Configuration, Environment variable, Static site
- Config drift
- When two environments meant to match end up with different configuration values, quietly.
- Production and staging run from the same infrastructure definition here, but each keeps its own set of values on purpose — see how that is kept from drifting unnoticed.
- See also: Configuration, Staging environment
- Third-party servicealso: third party, integration, outside service
- Anything an app calls, loads, or stores data in — a service somebody else runs, not us, not you.
- A payment gateway, a mail sender, a customer-messaging tool. It watches itself, backs itself up, and changes its own API, all on its own schedule, not ours. See the page that owns the whole boundary.
- See also: Webhook, Sandbox key, Secrets management
- Webhook
- A request a third-party service sends to your app on its own, when something happens on its side.
- The reverse of a normal call. Instead of your app asking, the far end tells you — a payment clears, a message gets delivered. Your app has to be ready to receive it at any time, not just while a visitor waits.
- See also: Third-party service
- Sandbox keyalso: sandbox mode, test key
- A test credential issued alongside the real one, so a check never touches a live customer.
- Wired into a staging copy in place of the live key. A rehearsal charge or a test text never reaches a real card or a real phone. Not every service offers one. Check per integration rather than assuming.
- See also: Third-party service, Staging environment
- Principle of least privilege
- Giving a person, process, or key only the access it actually needs, and nothing more.
- Applied to how our own systems and staff can reach your infrastructure — the fewer things that can touch production, the fewer ways it can go wrong. It is an operating principle here, not just a line written in a policy no one enforces.
- See also: Secrets management, Break-glass access
- Break-glass access
- A deliberate, logged use of elevated access to stop or fix a live incident — the exception, not the daily routine.
- Day-to-day work runs on named, scoped accounts; this is the escape hatch for the rare moment that isn’t enough on its own. Every use is recorded, and it’s named in the incident note you already get — never a quiet, unlogged detour around the normal path.
- See also: Principle of least privilege, Secrets management, Incident
- DDoS mitigationalso: Distributed denial-of-service protection
- Absorbing or filtering a flood of junk traffic aimed at taking a site offline, before it reaches your app at all.
- The edge network sits in front of every request, which means a volumetric attack has to get through tier-one infrastructure before it ever reaches a dedicated instance — the same protection whether a site gets ten visitors a day or ten thousand. This covers the flood only, not application-layer filtering — see the link for that line drawn plainly.
- See also: CDN (edge network), Firewall
- Rate limiting
- Capping how many requests a single visitor or address can make in a given window.
- Not switched on for you by default on a standard plan — real work we can build, quoted flat, once you know which endpoint needs it.
- See also: Firewall
- Bot trafficalso: scraper, scraping
- Automated requests, not a person in a browser — from a search engine indexing a page to a script pulling every price on the site.
- The edge network serves a bot's requests the same as a real visitor's; nothing here tells the two apart by default. Enough of it can add up against a fair-use transfer allowance.
- See also: Rate limiting
- Responsible disclosure
- Reporting a security hole privately, through a stated channel, before it becomes public.
- The quote form is the one channel in, for a customer or an outside researcher alike — no bounty, and no legal threat for a good-faith report.
- Encryption at rest
- Data encrypted while it is sitting in storage, not just while it is moving over the network.
- Backups, uploaded files, and database volumes are encrypted at rest here as a baseline, not an upsell — the same posture TLS gives a connection in transit, applied to the disk itself.
- See also: Backup, TLS certificate
- Honeypot fieldalso: spam trap, hidden field
- A form field real visitors never see or fill in — a submission that fills it is treated as spam.
- It costs a script nothing to fill in every field it finds, hidden or not. A human never sees it, so a filled-in honeypot is a reliable sign the submission was not a person. Forms shows this site's own form using one.
- See also: Form endpoint, Bot traffic
- Sessionalso: login session, user session
- The record that keeps a signed-in user signed in between requests.
- Where it lives decides what survives a release: held only in a running process's memory, it ends the moment that process restarts. Logins walks through every place one can live and what ends it.
- See also: Session cookie, Identity provider
- A cookie that carries a session, or a signed session itself, back to the browser that holds it.
- A signed cookie can hold the whole session on its own, with nothing stored on the server side at all — one of the places Logins names for where a session can live.
- See also: Session, Cookie
- Identity provideralso: auth provider, oauth provider
- An outside service that checks a login for your app — single sign-on, or a social login, instead of your app checking a password itself.
- It is one of the third-party services Outside services already covers, and a call your own app makes, not a service we run. Logins names it as one of the ways a login can break — the identity provider going down is an outage on their side.
- See also: Third-party service, Session
- Data controller
- The party that decides why personal data is collected and what happens to it.
- For the name and message in the quote form, that is us. For the personal data your own app collects from its users, that is you. Your data draws this line in full.
- See also: Data processor, Sub-processor
- Data processor
- The party that handles personal data on a controller's instructions, without deciding why it is collected.
- We are a processor for the personal data your app stores on hosting we run. You stay the controller. Your data lays out what that split means in practice.
- See also: Data controller, Sub-processor
- Sub-processor
- A party a processor brings in to help handle personal data, one step further from the controller.
- A mail sender or a payment gateway your app calls is a sub-processor for the personal data that call carries. Outside services already names the call itself; Your data names it as a place personal data can go.
- See also: Data processor, Third-party service
- Data residency
- The country or region where a copy of data actually sits.
- This site runs from one region, in the United States. We publish no region list and no residency guarantee beyond it — ask before you sign, not after. Your data has the full answer.
- See also: Data controller
№ 07 Money & billing
How the invoice gets decided
How the number on your invoice gets decided, and what it deliberately does not include.
- Flat-rate pricing
- One fixed monthly number for a plan, agreed up front, that does not move with traffic.
- A quiet month and a viral one cost the same here. It is the opposite of a bill that arrives as a surprise, and the reason a quote can be given in writing within a business day instead of hedged with "it depends on usage."
- See also: Usage-based pricing, Tier / plan
- Usage-based pricing
- A pricing model that charges by what actually gets used — requests, bandwidth, compute-seconds — instead of a fixed monthly number.
- Common elsewhere, and the reason some invoices are impossible to predict until they arrive. It is the model this page’s flat-rate pricing exists in contrast to: bill this way, and watching your own usage becomes a job you did not sign up for.
- See also: Flat-rate pricing, Overage
- Add-on
- An optional extra layered onto a base plan — CodeHerder’s iteration service, for instance — priced and named on its own line.
- Kept separate from the base plan so it is obvious what is driving the number on the invoice, rather than folded invisibly into a bigger tier.
- See also: Tier / plan
- Quote
- A specific fixed monthly rate, given in writing, for a workload described on the contact form.
- You describe what you are running; a real number comes back within a business day, not a call scheduled to discuss discussing it. Anything that does not fit a named plan gets designed and priced this way instead of forced into a tier that is wrong for it.
- See also: Flat-rate pricing, Estimate, Discovery call
- Estimate
- A number you build yourself, on the spot, from the posted rate card — not a quote.
- The estimator and the selector both produce one, and a spec sheet gives it a shareable link. Nobody on our side has seen it until you send it as a quote request.
- See also: Quote
- Discovery call
- A scheduled conversation some hosts require before they will price a workload. This one does not.
- A quote here comes back from the form alone, in writing, within a business day. A complicated or undocumented app can still need one round of written questions first, but never a booked call just to get a number.
- See also: Quote
- Overage
- An extra charge that lands on a bill because usage crossed a limit built into a usage-based plan.
- The line item that turns a predictable-looking plan into a surprising invoice the one month traffic spikes. It does not exist on a flat-rate plan. A fair-use allowance is not an overage meter — crossing it never adds a charge without a conversation first. That is a structural fact about the pricing model, not a promise about any specific month’s traffic.
- See also: Usage-based pricing
- Tier / planalso: plan
- A named, fixed configuration — Static Starter, Dedicated M, and so on — with a set price and a set specification.
- Named so a quote can reference something concrete rather than a bespoke negotiation every time: the same tier means the same CPU, memory, and price whenever it comes up.
- See also: Add-on, Flat-rate pricing, Vertical resize
№ 08 Shipping & iteration
Changing it after launch
The loop that keeps a site changing after launch, in plain terms.
- Repositoryalso: repo
- The one copy of your code that keeps a full history — every change, in order, with who made it and why.
- A running server or an emailed archive is a snapshot. A repository is the one of the three that a brief can actually be written against, because a change is a diff from a known point.
- See also: Commit, Version control, Branch
- Commit
- One recorded change to a repository — what changed, when, and by whom.
- A repository is a chain of these. A committed secret cannot be un-committed: rotating the value stops it working, but the commit that once held it stays in the history.
- See also: Repository, Version control
- Version controlalso: git
- The system that records every commit to a repository, so a project has a full history instead of a single, overwritten copy.
- Code that only lives on a running server has none of this. Import it into version control and its history starts on the day of the import — earlier changes were never recorded.
- See also: Repository, Commit
- Brief
- A plain-language description of a change you want made — a new page, a copy tweak, a small feature — written the way you would explain it to a person.
- No ticket template and no technical spec required, just what you want and why. It is the input to the loop: an agent reads it against the real codebase and turns it into a pull request.
- See also: Pull request, Agentic iteration
- Pull requestalso: PR, merge request
- A proposed change to a codebase, shown as a diff, waiting for someone to review it before it merges.
- Every change from a brief comes back as one of these, reviewed against the real repository before anything ships — never applied straight to production unseen. It is the same mechanism developers already use; CodeHerder’s agent just opens the request instead of a person typing the code.
- See also: Brief, CI, Merge
- Diff
- The exact lines a pull request adds or removes, shown next to the current code — the change itself, not a description of it.
- Every pull request carries one. You do not need to read it to review a change here — see Review for how to check one by using the staging link instead.
- See also: Pull request, Branch
- Branch
- A separate copy of the code a change is written on, so nothing it contains reaches production until it merges.
- The CodeHerder agent always writes on its own branch, never on the one that ships. Opening a pull request is how a branch gets proposed for review.
- See also: Pull request, Merge
- CIalso: Continuous integration
- The pipeline that automatically builds and checks a change the moment it is pushed, before a human even looks at it.
- The same pipeline that builds and deploys your app also runs on every pull request, so a broken change fails a check instead of reaching a reviewer’s screen looking fine. It is already running here; there is no separate CI service to wire up on your side.
- See also: Pull request, Build artifact, Deploy
- Status check
- A pass-or-fail result shown on a pull request, set by an automated check before a person reviews the change.
- A failed status check is a signal to fix something before anyone reads the diff. A pull request with every check green still needs a human decision — a passing check is not the same as a correct change.
- See also: CI, Pull request
- Test suite
- The tests your own application carries — what to assert is your call, checked automatically on every change.
- Hosting brings the build, the deploy, and the guards that check a published claim. It does not write what your own tests should assert — that needs your own knowledge of what correct looks like for your app.
- See also: Status check, Regression
- Regression
- A change that breaks something that used to work.
- A test suite exists mainly to catch this: a change made for one reason quietly breaking a different, unrelated part of the app. The earlier a check catches one, the cheaper it is to fix.
- See also: Test suite
- Flaky test
- A test that fails on and off, for no real code reason, rather than every time or never.
- A flaky test still blocks a deploy the same as a real failure. Fixing or removing it is a briefed change like any other — it does not get a free pass just because the failure is intermittent.
- See also: Test suite
- Agentic iteration
- An AI agent reading a brief, making the change in a real codebase, and opening a pull request — without anyone hand-writing the diff.
- This is what CodeHerder does against a site or app hosted here: the brief goes in, a pull request comes out, and a person reviews and merges it before it ships. The agent writes code; it does not get to skip the review.
- See also: Brief, Pull request, Merge
- Staging environmentalso: staging mirror
- A copy of a site or app, running for real, that is not the live version visitors see — where a change gets checked before it is.
- Migrations and cutovers get stood up here first and clicked through before DNS ever points at them for real, which is most of how "little-to-no downtime" gets kept as a promise rather than a hope. The same standing environment is also where a routine briefed change gets checked before it merges.
- See also: Rollback, Agentic iteration
- Schema migrationalso: database migration, db migration
- A change to a database's structure — a new column, a new table, a changed constraint — run as code, not clicked together by hand.
- Yours to write, or a CodeHerder brief's to open as a pull request. A snapshot is taken before it runs, and it ships inside the same deploy as the rest of the change, not as a separate manual step.
- See also: Managed database, Point-in-time recovery, Pull request
- Infrastructure as codealso: IaC
- Defining servers, DNS records, and configuration as versioned files instead of clicking them together by hand in a dashboard.
- Every piece of what runs here — the edge configuration, the DNS records, the certificates, the instance itself — is declared this way, reviewable like any other change. Nothing is clicked together by hand, so nothing is a mystery to whoever looks at it six months later.
- See also: CI
- Merge
- Approving a pull request and folding its change into the real codebase — the step that turns a proposed diff into what actually ships.
- This is deliberately yours: an agent can open a pull request, but merging it — the decision that it is correct and ready — stays a human call. The merge is usually what triggers the next deploy.
- See also: Pull request, Rollback, Deploy
- Deploy
- Taking a merged change from a build all the way to serving real traffic — publishing new files, or replacing a running process.
- The same seven steps run every time: build, check, produce an artifact, publish or replace, a health check, then retire the old version. Nothing is promoted until the step before it has passed.
- See also: Build artifact, Health check, Rollback
- Build failure
- A build that stops partway and produces no artifact — so there is nothing new to publish.
- Production keeps serving the last good version, because a failed build has nothing to switch to. The pipeline halts, and a human is told, on the same escalation ladder as any other fault.
- See also: Deploy, Build artifact
- Revert
- Undoing a merged change in code — as opposed to a restore, which brings data back.
- A revert redeploys the last known-good version through the same pipeline that shipped the change; no data is touched, because none was. A problem with data, rather than code, is a restore instead — a different procedure entirely.
- See also: Rollback, Merge
- In flight
- A briefed change that has started and has not yet merged — the one thing moving through the loop right now.
- Only one change is in flight at a time on a given branch. A second change waits its turn rather than running alongside the first.
- See also: Work in progress limit, Pull request
- Work in progress limitalso: WIP limit
- A cap on how many changes move through a pipeline at once — here, one.
- One pipeline and one main branch mean one change in flight at a time. Briefing a second change does not start a second lane; it takes its place in the order behind the first.
- See also: In flight, Change queue
- Change queue
- The order a set of briefed changes ships in — set by you, not re-ranked here.
- You set the order you brief changes in, and that is the order they ship in. The one exception is a flagged security dependency, which moves to the front through its own lane.
- See also: Work in progress limit, Brief
Know what you're running yet?
Describe it on the quote form, plain language is all we need — one fixed monthly rate, in writing, within a business day.