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.
45 of 74terms on this page are things you never have to touch.
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
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
- 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
- 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
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
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 posted to a public status history here rather than handled quietly and forgotten — an honest incident record is worth more than a page that is always green with nothing to show for it.
- See also: Uptime, SLA, Break-glass access
- 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
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: Infrastructure as code, 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
- 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
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
- 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
Changing it after launch
The loop that keeps a site changing after launch, in plain terms.
- 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
- 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
- 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
- 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
Keep exploring
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.