Answers, not
ticket queues.

Codepillar Hosting is managed web hosting bundled with Codepillar, our split-pane live editor. Instead of buying server space from one company and hiring a developer or agency to make changes, you get both from one place: infrastructure that's monitored, patched, and backed up, plus an editor that lets you change your own site without touching code.

Think of it as the difference between renting an apartment and renting an apartment with a superintendent who also hands you a way to repaint the walls yourself, anytime, without submitting a request. We handle uptime, security, and backups in the background; you handle the day-to-day content because you're the one who knows when the sale ends or the hours change.

Every plan — Starter, Growth, and Business — includes hosting and at least one Codepillar editor seat. The difference between tiers is how many sites you can run, how much storage you get, and how many people on your team can edit at once. See the pricing page for the full breakdown.

Signup itself takes minutes, but getting your site fully live involves a few steps that happen mostly on our side:

1. Account and plan setup (~15 minutes). You choose a plan, and we provision your hosting environment — storage, SSL, and your Codepillar editor seats.
2. Intake review (within a few hours). If you told us about an existing site or sent a brief, a developer reviews it and starts staging your site on our infrastructure.
3. Staging and verification (same day, sometimes into day two). Your site is built or migrated on a staging URL first, so nothing goes live broken. We check pages, forms, and images before touching your real domain.
4. DNS cutover. Once staging looks right, we send you the DNS records to update at your registrar, or make the change ourselves if you've given us access. This is the step that isn't fully in our control timing-wise — see the DNS propagation article below.

For a straightforward migration, most customers are fully live within 24–48 hours. Larger or more custom sites can take longer; we'll tell you upfront if that's the case rather than let a deadline slip quietly.

DNS (Domain Name System) is the internet's phone book — it's what translates yourdomain.com into the actual server address where your site lives. When we point your domain at our servers, that change has to spread across thousands of DNS servers worldwide before every visitor sees the update. That spreading process is "propagation."

Most propagation completes within 1–4 hours, but it can technically take up to 48 hours in rare cases, because some networks cache DNS records for longer than others. During that window, some visitors might briefly see your old site and others see the new one — this is normal and not an error.

We always stage and verify your site before touching DNS, so propagation delay affects when visitors see the new site, not whether it works. If it's been more than 48 hours and your domain still isn't resolving to the new site, that's worth checking as a real issue, not normal propagation.

You're billed automatically on the card on file, either monthly or annually depending on what you chose at signup. Monthly plans renew on the same calendar date each month; annual plans renew on the same date each year. There's no usage-based surprise billing — your plan price is fixed regardless of traffic, as long as you're within your plan's storage and site limits.

Plans are month-to-month by default, meaning there's no long-term contract locking you in. Choose annual billing instead if you want the discount described below — it's optional, not required.

Invoices and receipts are emailed automatically after every charge. If you need one reissued or need to update billing contact details, email us directly and a developer (not a billing bot) will sort it out.

Just tell us — email or message us which plan you want to move to. Because support here means talking to the person running the platform, plan changes aren't a self-serve toggle buried in a dashboard; we make the change and confirm it with you directly, usually the same day.

Upgrading (Starter → Growth → Business) takes effect immediately: more sites, more storage, more Codepillar editor seats, and any tier-specific features like staging or dedicated resources become available right away. You're only charged the prorated difference for the rest of the current billing period.

Downgrading takes effect at the start of your next billing cycle, not immediately — this avoids any mid-cycle scramble to delete sites or free up storage. If a downgrade would put you over the new plan's site or storage limits, we'll flag that before confirming so you can decide what to trim.

Nothing goes down immediately. If a charge fails — expired card, insufficient funds, bank flag — we email you right away and retry the charge automatically over the following days. Your site, editor access, and backups keep running normally during this grace period.

If payment still hasn't gone through after the retry window, we'll reach out directly (not just another automated email) before any suspension. Sites are only paused as an absolute last resort after repeated failed attempts and no response — we'd rather fix a billing hiccup than take your site offline over it.

To avoid this entirely, keep your card details current. If you know a card is about to expire, updating it proactively takes thirty seconds and saves everyone a back-and-forth.

Annual billing saves roughly 15% compared to paying monthly on any plan — Starter, Growth, or Business — and is worth it if you're confident you'll be on the platform for the year. It's one upfront charge instead of twelve, which also means one less thing to think about.

Monthly billing makes sense if you're just getting started, testing whether Codepillar Hosting is the right fit, or your business has seasonal cash flow and you'd rather not commit a year of spend at once. There's no penalty for starting monthly and switching to annual later — just ask.

Neither option locks you into a long-term contract beyond the billing period you've already paid for. Annual billing is a discount for prepaying, not a cancellation trap.

Codepillar is a split-screen editing view: your site's real code sits on one side, and a live, instant preview sits on the other. When you or a developer changes something on the code side, the preview side updates immediately — no save-and-refresh, no separate deploy step, no waiting for a build to finish.

This matters because it closes the gap between "I want to change this" and "I can see that it worked." Non-technical business owners typically work from the preview side using simple editing controls for text, images, and layout, while developers can drop straight into the code side when something needs precision. Both views are editing the same underlying, real code — there's no proprietary format or lock-in layer in between.

You'll get a Codepillar editor link and login for your site as part of onboarding, once your site is staged. Bookmark it — that link is your day-to-day entry point for making changes, and it's the same for every seat on your account.

Each seat on your plan (1 on Starter, 3 on Growth, unlimited on Business) is a separate login, so you can invite teammates without sharing one password. If you've lost your link or need to add a seat, email us and we'll get it sorted the same day.

When you make a change in the editor, it renders instantly in the preview pane — this is what "live" means here. Nothing is published to your public site until you explicitly save or publish the change, so you can experiment freely without worrying about visitors seeing a half-finished edit.

Once you're happy with how something looks in preview, saving pushes it live immediately. There's no queue and no separate deploy pipeline to wait on — the same speed that makes the preview instant is what makes publishing instant too. Growth and Business plans additionally get a staging environment, so bigger changes can be tested on a separate, non-public URL before touching the live site at all.

Give a seat to anyone who regularly needs to change something on the site without waiting on someone else — usually the business owner, a marketing or content lead, or an office manager who updates hours, pricing, or promotions. If someone touches the site more than once a month, they should probably have their own login rather than relaying change requests through a teammate.

On Starter, you get one seat — fine for a solo owner-operator. Growth includes three, which typically covers an owner plus a couple of content or marketing people. Business includes unlimited seats, built for teams where several people — including outside contractors or an agency — need access at once.

One extra tip: seats are also useful for handoff. If you eventually bring on your own developer, giving them a seat lets them work directly in the same real codebase Codepillar edits — nothing to migrate or explain.

You send us access to your current site — hosting login, a code export, or even just the live URL if it's simple enough to rebuild — and we take it from there. A developer copies your content, pages, and assets onto our infrastructure and rebuilds anything that needs it to run cleanly on managed hosting with the Codepillar editor attached.

The whole thing happens on a private staging URL first. Nothing about your live site changes until we've checked that the migrated version matches — same pages, same content, working forms and images — and you've had a chance to look at it yourself if you want to.

Only after staging is verified do we move to DNS cutover, pointing your domain at the new hosting. That sequencing — build first, verify second, switch last — is what keeps migrations safe instead of a gamble on launch day.

In almost all cases, no. Because we build and verify your site on staging before ever touching your live domain's DNS, your current site keeps running normally on its existing host right up until the cutover moment. There's no window where your site is offline for "the migration" itself.

The one variable outside our control is DNS propagation after cutover — see the DNS propagation article for why that can take a few hours. During propagation, visitors see either the old or new site depending on their network, but they always see a working site, never a blank page or error.

Email is the one exception worth planning around: if your email also runs through DNS records tied to your domain (MX records), we'll coordinate that switch carefully so inbound mail doesn't get dropped — see the email troubleshooting article for what to check if that ever looks off.

We don't delete or alter your original site during migration — it stays exactly as it was on its previous host until you've confirmed the new one is working the way you expect. That means if something looks wrong right after cutover, DNS can be pointed back to the old host just as quickly as it was pointed to the new one.

On top of that, every site on Codepillar Hosting starts taking automated backups from the moment it goes live (frequency depends on your plan tier — see the Security & Backups section). So even after cutover, you're never more than one restore away from a known-good state if an edit or update causes a problem down the line.

In short: nothing is destructive until you say it's good. That's a deliberate design choice, not a lucky side effect.

You don't need to move your domain registration anywhere — you can keep it registered wherever you originally bought it (GoDaddy, Namecheap, Google Domains, etc.) and just point it at our hosting using DNS records. We'll give you the exact records to add once your site is staged and ready.

In most cases this means logging into your registrar's DNS settings and adding or editing a couple of records — usually an A record and a CNAME (see the record types article below). If you'd rather not touch it yourself, send us access and we'll make the changes directly.

Once the records are saved, propagation takes over — allow a few hours for the change to fully take effect everywhere.

You'll typically only deal with a handful of record types. Here's what each one does:

1. A record — points your domain directly at a server's IP address. This is usually the core record connecting yourdomain.com to our hosting.
2. CNAME record — points a subdomain (like www) to another domain name instead of an IP. We often use this for www.yourdomain.com.
3. MX record — routes your email. If you use a separate email provider (Google Workspace, Microsoft 365, etc.), these need to stay pointed at that provider — we'll never ask you to change MX records unless email is moving too.
4. TXT record — used for verification and security purposes, most commonly SSL validation and anti-spam settings like SPF/DKIM for your email.

We'll always tell you exactly which records to add or change, with the exact values — you won't need to guess or research DNS syntax yourself.

SSL — the certificate that makes your site load as https:// with the padlock icon — is included and automatically managed on every plan, Starter through Business. You don't purchase or renew it separately, and you don't need to do anything technical to keep it active; certificates renew automatically before they expire.

HTTPS matters for two practical reasons: browsers flag non-HTTPS sites as "not secure," which erodes visitor trust, and it's a baseline factor in how search engines rank sites. Both are handled the moment your site goes live on our infrastructure — there's no separate step or upcharge to switch it on.

All plans include automated backups — no tier goes without protection. Where plans differ is priority and frequency:

1. Starter ($39/mo): automated backups included, run on our standard nightly schedule.
2. Growth ($89/mo): priority backups — your site is backed up more frequently and restored faster if you ever need it, reflecting the higher traffic and stakes of running multiple sites.
3. Business ($199/mo): backups run alongside dedicated resources and an SLA-backed uptime commitment, giving established teams the fastest recovery path available on the platform.

Backups are stored separately from your live site, so a problem with your site — a bad edit, a plugin conflict, anything — doesn't put your backups at risk too.

Email or message us and tell us roughly when things last looked right — "yesterday afternoon" is plenty specific. A developer pulls the nearest backup and restores it, rather than having you dig through a self-serve restore panel and guess which snapshot is safe.

Restores don't touch your domain or DNS setup — only the site content and files themselves — so there's no propagation delay involved; a restore is typically live again within the hour on Growth and Business, and same-day on Starter.

If you're not sure whether you need a full restore or just want to undo one recent edit, ask first — sometimes a manual fix in Codepillar is faster and more surgical than rolling back an entire backup.

Server software, the hosting stack, and platform-level dependencies are patched automatically and continuously in the background — this is part of what "managed" means. You don't get prompted to approve updates or schedule maintenance windows; if a security patch needs applying, we apply it.

SSL, firewall rules, and hardened server configurations are set as the baseline on every plan from day one, not an add-on you opt into. If a patch ever requires a brief service interruption (rare, and typically seconds, not minutes), we schedule it for low-traffic hours and it's covered by the backup safety net described above regardless.

Before assuming the worst, run through this quickly:

1. Check it from another network. Try your phone on cellular data instead of Wi-Fi, or ask someone in a different location to load the site. Sometimes it's a local network or DNS cache issue on your end, not the site itself.
2. Check if you recently changed DNS. If you or your registrar changed any DNS records in the last 48 hours, you may just be inside a normal propagation window.
3. Check for a recent unsaved or bad edit in Codepillar. If someone on your team made a change right before the issue started, that's the most common cause — and the easiest to fix by editing it back or asking us to restore a backup.
4. Check the browser error message. "This site can't be reached" usually points to DNS; a broken layout or missing content usually points to a content edit, not an outage.

If none of that explains it, contact us immediately — this is the one category of issue where speed matters most, and as a paying customer you get a direct line to a developer, not a ticket queue.

Start with the basics: hard-refresh the page (Ctrl/Cmd + Shift + R), and try a different browser or an incognito/private window. Editor issues are very often a stuck cache or a browser extension (particularly ad blockers or script blockers) interfering with the live preview pane.

If it still won't load, check whether you're using the correct, current editor link — links aren't meant to expire, but if your seat was recently reassigned or added, an old bookmarked link can sometimes point at a stale session. Log out and back in using the link from your original onboarding email.

Still stuck? Send us a screenshot of what you're seeing along with the browser and device you're using — that's usually enough for us to diagnose it fast without a long back-and-forth.

Email almost never runs through the same hosting as your website — it's typically routed by MX records pointing at a separate provider like Google Workspace or Microsoft 365. If email broke right after a DNS change, the most common cause is an MX record getting accidentally overwritten or removed while updating the records that point your domain at our hosting.

We're careful to leave MX and email-related records untouched during migrations and DNS cutovers specifically because of this risk, but it's worth double-checking your registrar's DNS panel to confirm your MX records still show your actual email provider, not a default or blank value.

If they've been changed or removed, restoring them (or asking us to) typically fixes mail flow within a few hours as those records repropagate. If you're not sure what your MX records are supposed to be, tell us who handles your email and we'll help you get the correct values back in place.