№ 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.

№ 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.
CustomHostedPerformance
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.
CustomHostedPlatform
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.
SharedPerformance
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.
CustomHostedPricing
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.
CustomHostedDelivery
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.
SharedStatic hosting
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.
CustomHostedDelivery
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.
CustomHostedDelivery
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.
SharedDelivery
See also: Static site
№ 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.
SharedStatic hosting
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.
CustomHostedDedicated compute
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.
CustomHostedDatabases
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.
SharedDocker
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.
CustomHostedDedicated compute
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.
SharedThe loop
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.
CustomHostedFiles
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."
SharedBackground jobs
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.
SharedBackground jobs
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.
CustomHostedBackground jobs
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.
YouBackground jobs
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.
CustomHostedScaling
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.
CustomHostedScaling
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.
CustomHostedScaling
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.
SharedFiles
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.
CustomHostedFiles
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.
YouFiles
See also: Persistent disk, Object storage
№ 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.
CustomHostedDomains
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.
CustomHostedDomains
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.
CustomHostedDomains
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.
YouDomains
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.
SharedDomains
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.
CustomHostedDomains
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.
CustomHostedEmail
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.
CustomHostedEmail
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.
CustomHostedEmail
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.
CustomHostedEmail
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.
SharedEmail
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.
SharedEmail
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.
CustomHostedMonitoring
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.
CustomHostedSLA
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.
CustomHostedRecovery
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.
CustomHostedRecovery
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.
SharedDatabases
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.
CustomHostedEnvironments
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.
CustomHostedMonitoring
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.
CustomHostedMonitoring
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.
CustomHostedLogs
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.
YouLogs
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.
CustomHostedLogs
See also: Request log, Backup
№ 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.
CustomHostedPatching
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.
CustomHostedUnder attack
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.
SharedAccess
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.
SharedDatabases
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.
CustomHostedAccess
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.
CustomHostedAccess
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.
CustomHostedUnder attack
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.
SharedUnder attack
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.
CustomHostedUnder attack
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.
SharedUnder attack
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.
CustomHostedSecurity
See also: Backup, TLS certificate
№ 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."
CustomHostedBilling
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.
YouBilling
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.
CustomHostedBilling
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.
SharedGet a quote
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.
YouBilling
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.
CustomHostedBilling
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.

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.
SharedBrief a change
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.
SharedBuilt in the open
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.
CustomHostedThe loop
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.
SharedThe loop
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.
CustomHostedEnvironments
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.
YouDatabases
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.
CustomHostedPlatform
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.
YouBuilt in the open
See also: Pull request, Rollback

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.

Get a quote