Offshore Hosting

Blog

  • Recovering From a Hacked Website: First Steps, Cleanup and Hardening

    Key takeaways

    • First contain the site, preserve an evidence copy and logs, and work from a clean device — do not start by deleting.
    • Rotate credentials in order (hosting, registrar, email, then site, database and server access) and revoke sessions, keys and API tokens.
    • Restore only a backup you are sure predates the compromise; otherwise rebuild core and extensions from official sources and audit uploads, custom code and the database.
    • Recovery is not finished until the entry point is closed, updates and backups run on a routine, and admin access is least-privilege with two-factor authentication.

    The signs are usually unmistakable: your site redirects visitors somewhere disreputable, the browser warns it is dangerous, search results show pages you never wrote, or your host suspends the account and sends a malware notice. What you do in the first hour decides whether this becomes a bad day or a bad month. This guide gives the order of operations — and the order matters, because the instinctive moves (delete things quickly, restore the first backup you find) can destroy the evidence you need and reinstate the problem you are trying to remove.

    Step 1: Contain, and do not panic-delete

    Take the site offline or put it behind a maintenance page. A hacked site that stays live keeps harming visitors, keeps spreading whatever it is serving, and keeps damaging your search reputation. If your host has suspended the account already, that containment is done for you — annoying, but useful.

    Then, before changing anything else: preserve evidence. Download a complete copy of the site’s files and database as they are now, and note the server and access logs if you can reach them. This infected copy is not for restoring — it is for answering the question every cleanup depends on: how did they get in? Delete first and you will never know, which means you cannot close the door they used.

    Work from a clean device, and run a malware scan on your own computer too. If your machine is compromised, every new password you type is a gift to the attacker.

    Step 2: Change the locks — in the right order

    From the clean device, change passwords in this order: hosting account and control panel first, then your registrar and email (the accounts that can reset everything else), then the site’s admin accounts, database password, and FTP/SFTP/SSH credentials. Enable two-factor authentication wherever it is offered as you go.

    Also revoke what passwords do not cover: application passwords, API keys, and — on WordPress — the security keys and salts in the configuration, which invalidates every logged-in session, including the attacker’s. Assume anything stored in the site (including keys inside configuration files) has been read.

    Step 3: Find the entry point

    Most small-site compromises come from a short list: an outdated plugin, theme or CMS core; a weak or reused admin password; a nulled (pirated) plugin or theme carrying a backdoor from the start; or credentials stolen from an infected computer. Look for the evidence: files modified around the incident date, administrator accounts you do not recognise, scheduled tasks and cron jobs you did not create, and log entries showing the first suspicious access. Your host’s security team or a malware scanner can help identify malicious files, but treat scanner output as leads, not gospel.

    Step 4: Clean, or rebuild — honestly

    There are two honest routes back:

    Restore a known-good backup. If you have a backup from before the compromise — and you can date the compromise well enough to know the backup is clean — restoring it is the fastest safe path. Restoring a backup taken after the break-in restores the backdoor with the site. If you cannot be sure a backup predates the incident, it is not known-good.

    Clean the installation. Replace the CMS core and every plugin and theme with fresh copies from their official sources (this alone removes most injected code, which hides in modified core and plugin files), then audit what cannot be replaced: the uploads directory (a classic hiding place — it should contain media, not executable code), custom code, the database (injected admin users, poisoned options and content), and configuration files. Delete anything you cannot account for; every legitimate file can be re-downloaded, while one surviving backdoor restarts the whole incident.

    Whichever route you take, update everything to current versions as part of the recovery — returning with the same outdated component that let them in is an invitation.

    Step 5: Go back online carefully

    Before reopening: change the database password and update the configuration to match, confirm no rogue admin accounts exist, and review file permissions. Then bring the site up and check it as a visitor — the pages, the forms, the checkout if you have one. If search engines flagged the site, request a review through their webmaster tools once you are confident it is clean; asking before it is clean wastes the review. Tell your host what you found and did; hosts see the server-level picture you cannot, and a suspended account usually needs their sign-off to reopen.

    If the compromise may have exposed customer data — names, emails, order details — take advice on your obligations to notify. That duty varies by jurisdiction, and guessing wrong in either direction is costly.

    Step 6: Harden, so the post-mortem has a point

    • Updates on a routine, not a hope. Core, plugins and themes updated promptly; unused ones deleted entirely — an inactive vulnerable plugin is still executable code on your server.
    • Least privilege. Separate admin accounts per person, no shared “admin”, and two-factor authentication on admin logins.
    • Backups you have tested. Automatic, kept off the server, with a restore you have actually rehearsed. Backups are what turn the next incident from a rebuild into a restore.
    • A malware scanner or file-integrity monitoring, so the next change is noticed in hours, not by a customer.
    • Close the specific door. Whatever the entry point was — a plugin, a password, a pirated theme — name the change that closes it. “Be more careful” is not a control.

    When to hire help

    Bring in professional cleanup help if the site takes payments, holds significant customer data, keeps getting reinfected after your cleanup, or if the steps above exceed what you can do confidently. Reinfection after cleanup almost always means a backdoor or the entry point survived — that is precisely the situation specialists exist for, and paying for it is cheaper than a second public incident.

    After reopening: watch for reinfection

    Reinfection in the first few days is the classic sign that something survived — a backdoor file, a rogue account, a credential you missed. For the first week, check the site daily: new admin users, recently modified files, and the scanner’s reports. Keep the evidence copy and your notes from the cleanup until that week has passed clean; if the site is hit again, the comparison between the two incidents is the fastest route to the hole you missed.

    If it does come back, do not simply repeat the same cleanup louder. Escalate: that is the moment for professional help or for rebuilding the site from scratch — fresh installation, content exported and inspected, nothing executable carried over. A second reinfection is information, and it is telling you the problem lives somewhere your cleanup did not reach.

    The bottom line

    A hacked site is recovered in order: contain, preserve, lock out, investigate, rebuild clean, harden. The sites that suffer twice are the ones that skipped the investigation and restored the problem, or cleaned the files and left the door open. Do the steps in order and the incident becomes what it should be — a bad day with a written lesson attached, not the first of several.

    Reviewed 25 October 2026. Steps described are the general recovery pattern for CMS-based sites such as WordPress; server-level incidents on a VPS add the operating system to the audit scope. What incident help Offshore Hosting support will provide is [TO BE CONFIRMED] — ask before you need it, not during an incident.

    Related guides

    Related service: Knowledge Base

  • Reseller Hosting Explained: Sell Hosting Without Running Servers

    Key takeaways

    • Reseller hosting lets you sell branded hosting accounts on a provider’s server; the provider runs the hardware, you run the customer relationship.
    • It suits designers, agencies, and freelancers who want recurring revenue and account separation without server administration.
    • You are your customers’ support desk — that responsibility, not the technology, is the real commitment.
    • Judge plans on per-account limits, backup arrangements, white-label completeness, and how easily you could leave.

    Most hosting customers never think about where their hosting comes from. Many small hosting brands — especially the ones run by web designers and small agencies — do not own servers at all. They buy reseller hosting: a wholesale arrangement that lets them create hosting accounts for their own customers, under their own brand, on someone else’s infrastructure.

    This guide explains what reseller hosting is, how it works day to day, who it suits, and what to check before you build a business on top of it.

    What reseller hosting is

    A reseller plan gives you an allocation of server resources — disk space, bandwidth, and the right to create a set number of hosting accounts — on a server the provider owns and maintains. You divide that allocation into packages of your own design, set your own prices, and sell them to your customers. Your customers log in to a control panel carrying your brand, not the provider’s. This arrangement is called white-label hosting.

    The provider’s job is the server itself: the hardware, the operating system, the control panel licensing, security patching, and keeping the machine online. Your job is everything customer-facing: selling, billing, first-line support, and deciding how the resources are split.

    How it works in practice

    On a typical cPanel-based reseller plan, you manage everything through WHM (Web Host Manager), the reseller-level panel that sits above cPanel. From WHM you:

    • Create packages — combinations of storage, bandwidth, email accounts, databases, and other limits that you sell as your plans.
    • Create and suspend accounts — one cPanel account per customer, which you can suspend for non-payment or upgrade when they outgrow a package.
    • Brand the experience — your logo in the panel, your nameservers (for example, ns1.yourbrand.com), and your support details.

    Your customers see an ordinary hosting account. They never need to know a provider sits behind you — unless something goes wrong at server level, at which point you open a ticket with the provider and keep your customer informed.

    Who reseller hosting suits

    Web designers and developers are the classic resellers. A client who has just paid for a website also needs hosting and usually prefers one invoice and one person to call. Hosting those clients yourself turns a one-off project into recurring revenue and keeps the client’s site on infrastructure you know.

    Small agencies use reseller plans to keep client sites separated — one account per client — without administering a server. Separation matters: one client’s hacked site or traffic spike is contained to their account, and handing over a finished project is as simple as transferring the account.

    Freelancers and side businesses use reseller hosting as a low-cost entry into selling hosting. There is no hardware to buy and no server licence stack to assemble; the monthly cost is the plan itself.

    Who it does not suit

    Reseller hosting is still shared infrastructure. You do not get root access, you cannot install server-wide software, and your performance ceiling is the plan’s resource allocation. If your customers run heavy stores, custom applications, or anything needing server-level control, they belong on VPS hosting — and reselling VPS or dedicated servers is a different, more technical business.

    It also does not suit anyone who wants the income without the support. When your customer’s email stops working at 9 p.m., they call you, not the provider. First-line support is the product you are actually selling.

    How to start

    1. Decide who you are selling to. Existing design clients, a local niche, or the open market — the answer shapes your packages and prices.
    2. Choose a provider and plan using the checks in the next section. Start with a plan sized for your first handful of customers; reseller plans can usually be upgraded as you grow.
    3. Set up your packages and branding — nameservers, panel logo, and two or three simple packages rather than a confusing matrix.
    4. Arrange billing. Many resellers use a billing system such as WHMCS to automate signups, invoicing, and suspensions; others bill manually while customer numbers are small. Either way, decide before the first sale, not after.
    5. Write your terms. What support hours you offer, what you will and will not fix, and what happens on non-payment — in plain language, before you need them.
    6. Migrate or create the first accounts and test everything as a customer would: email, backups, SSL, and the support route.

    What to check before choosing a reseller plan

    • The real resource limits. Total storage and bandwidth are headlines; the limits that bite are per-account CPU and memory, inode counts, and how many accounts you may create. Ask for them in writing.
    • Overselling policy. Some providers let you sell more resources than your allocation, betting customers will not use them all. That keeps prices low but risks a hard stop when usage grows. Know which model you are on.
    • White-label completeness. Custom nameservers, a branded panel, and neutral invoices and emails — check that nothing customer-visible carries the provider’s name.
    • Backups. Who backs up your customers’ accounts, how often, and can you restore a single account yourself? Your customers will assume you can.
    • Uptime and support behind you. Your reputation rests on a server you do not control. A provider whose support answers resellers quickly, at night, is worth more than a slightly cheaper plan.
    • The exit. Can you export every account in full if you move providers? A reseller business you cannot move is a hostage, not an asset.
    • Licence and billing costs. The plan price is not your only cost: billing software, a domain, and payment fees come out of your margin. Price your packages with those included.

    Pricing your packages

    Reseller pricing fails in two directions: so cheap that support time makes every customer a loss, or plucked from a competitor’s page without knowing your own costs. The grounded way is to work upwards from what you spend. Your costs are the plan itself, billing software if you use it, your domain and payment fees, and — the one everyone forgets — your time. An hour of support per customer per month is a real cost even if nobody invoices you for it.

    Then look at what the package contains: customers compare storage, bandwidth and mailbox counts because those are the numbers they can see. Competing purely on those numbers against hosts with a thousand times your volume is a race you will lose. The resellers who keep customers sell the things large hosts cannot: a person who knows their site, migration done for them, and support that answers in their language and timezone. Price for that, and state clearly what is included — the customers worth having are buying relief from worry, not gigabytes.

    The bottom line

    Reseller hosting is the simplest honest way to sell hosting: real accounts, real separation between customers, and no servers to maintain. It works when you treat support as part of the product and choose a provider whose limits and backups you have read properly. If your customers outgrow shared resources, the natural next step is reselling — or moving them to — VPS hosting, not squeezing a reseller plan harder.

    Reviewed 25 October 2026. Whether Offshore Hosting will offer reseller plans, and on what terms, is [TO BE CONFIRMED] — this article does not state them. Control panel features described are the standard WHM/cPanel reseller model; confirm the exact feature set with any provider before buying.

    Related guides

    Related service: Hosting plans

  • HTTP/3 and QUIC Explained: What Changes for Your Website

    Key takeaways

    • HTTP/3 runs on QUIC over UDP instead of TCP, so one lost packet no longer stalls the whole page.
    • QUIC combines the transport and TLS handshakes, encrypts by default, and keeps connections alive when a device changes networks.
    • HTTP/3 polishes delivery; it does not fix a slow server, heavy pages, or missing caching.
    • For most site owners, enabling it is a host, server or CDN setting, plus making sure UDP port 443 is open, and browsers fall back to HTTP/2 gracefully when it is unavailable.

    Every web page you have ever loaded arrived over HTTP. The protocol has been revised in generations — HTTP/1.1, then HTTP/2, and now HTTP/3 — and each revision exists because the previous one hit a limit on real networks. HTTP/3 is the first version to replace the transport underneath it: instead of TCP, it runs on QUIC, a newer transport protocol built on UDP. This guide explains what that means, what it improves, and what — if anything — you need to do as a site owner.

    A short history, because it explains the design

    HTTP/1.1 loads resources largely one queue at a time per connection, so browsers open several connections and pages still wait in line. HTTP/2 fixed much of that by multiplexing: many requests share one connection and interleave. But HTTP/2 still runs over a single TCP connection, and TCP delivers bytes strictly in order — if one packet is lost, everything behind it waits while it is resent, even data that arrived fine. On a perfect network this rarely matters. On mobile and congested networks, it does. HTTP/3, standardised by the IETF as RFC 9114 in 2022 and built on QUIC (RFC 9000), removes that bottleneck by moving multiplexing into the transport itself: each stream is independent, so a lost packet stalls only its own stream.

    What QUIC changes

    Independent streams. A single lost packet no longer holds up the whole page. Images, scripts and text recover separately, which is where the real-world speed gain on lossy connections comes from.

    A faster handshake. QUIC folds the transport handshake and the TLS 1.3 encryption handshake into one exchange, so a connection is ready sooner than TCP plus TLS managed separately. For repeat visits, QUIC can resume with even less back-and-forth — with the caveat that the fastest resumption mode trades away some replay protection, which is why cautious servers limit what it can be used for.

    Encryption by default. TLS is built into QUIC rather than bolted on. There is no unencrypted HTTP/3.

    Connections that survive network changes. TCP identifies a connection by IP addresses and ports, so moving from Wi-Fi to mobile data breaks it. QUIC identifies connections by an ID, so a connection can migrate across networks — your phone keeps its session as you walk out of the office.

    What HTTP/3 does not change

    It does not make a slow server fast, shrink a heavy page, or fix an overloaded database. If your site waits two seconds on the server before responding, HTTP/3 delivers that wait slightly more efficiently. The order of work for a slow site is unchanged: fix server response and caching first, page weight second, protocol last. Nor does HTTP/3 change anything about how your site is built — no code changes, no new markup. It is negotiated between the visitor’s browser and whatever terminates your HTTPS connection.

    What a site owner needs to do

    Usually, very little:

    1. Check whether your host or CDN already enables it. Many CDNs and modern web servers offer HTTP/3 as a setting or enable it by default. Browsers discover it through the Alt-Svc header or HTTPS DNS records, and quietly upgrade when both sides support it — visitors on older setups simply keep using HTTP/2.
    2. If you run your own server, support depends on your software: LiteSpeed supports QUIC and HTTP/3 natively; nginx has HTTP/3 support in its current releases; Apache relies on additional modules or a proxy/CDN in front. Check your server’s documentation for the current state rather than relying on any article, including this one.
    3. Make sure UDP is not blocked. QUIC runs over UDP on port 443. A firewall that only opens TCP 443 will silently prevent HTTP/3 — browsers fall back to HTTP/2, so nothing breaks, but the benefit never arrives.
    4. Verify. Browser developer tools show the protocol used for each request, and free online checkers will test your domain. Verify once after enabling; after that it needs no attention.

    Should you chase it?

    If it is one toggle in your panel or CDN, yes — the cost is minutes and the benefit shows up for exactly the visitors worst served today: mobile users and anyone on an unreliable connection. If enabling it means changing hosts or rebuilding your stack, no — put it on the list for the next time you touch the setup, and spend the effort on caching and page weight first, where the larger gains still live.

    HTTP/2 and HTTP/3 at a glance

    Aspect HTTP/2 HTTP/3
    Transport TCP, one connection QUIC over UDP
    Multiplexing Many streams, but one lost packet stalls all of them Independent streams; a lost packet stalls only its own
    Connection setup TCP handshake, then TLS handshake Combined transport and TLS handshake
    Encryption TLS in practice (required by browsers) TLS 1.3 built into the protocol
    Changing networks Connection breaks; a new one is opened Connection can migrate (for example, Wi-Fi to mobile data)
    If unsupported — Automatic fallback to HTTP/2 or HTTP/1.1

    Why the fallback behaviour matters

    HTTP/3 was designed to be safe to switch on: no visitor is ever stranded. A browser that cannot use QUIC — an old browser, a network that blocks UDP, a corporate firewall — simply continues over HTTP/2 or HTTP/1.1, invisibly. That is also why enabling it is low-risk as an experiment: you can turn it on, measure, and turn it off, and at no point does the site stop working for anyone. The same cannot be said of many performance changes, which is another reason HTTP/3 belongs in the do it when convenient category rather than the handle with care one. What measurements should you expect? Honest answer: modest ones, concentrated on visitors with poor connections. A site whose audience is local, on fast connections, to a nearby server may see little change. A site serving a global, mobile-heavy audience over long distances is where the protocol earns its keep — which is also why CDNs adopted it early: their entire business is those visitors.

    A note on names for the same thing

    Because hosts expose HTTP/3 through different switches, you will meet several labels for this one feature: QUIC, HTTP/3, QUIC.cloud on some CDN dashboards, and UDP 443 in firewall rules. They all refer to the same arrangement described here. If your panel offers a QUIC toggle, that is the HTTP/3 toggle — there is no second feature hiding elsewhere in the settings. Conversely, a speed or protocol optimisation bundle may include HTTP/3 among other things; the developer-tools check described above is the reliable way to confirm what your visitors are actually using, whatever the dashboard calls it.

    The bottom line

    HTTP/3 and QUIC are a genuine improvement aimed at real networks rather than benchmarks: less waiting when packets are lost, faster connection setup, sessions that survive a move from Wi-Fi to mobile data. They are also, for a site owner, refreshingly boring — usually a setting to switch on and verify, not a project. Switch it on where it is easy, confirm UDP is open, and keep your speed efforts aimed at the server and the page, where they pay off most.

    Reviewed 25 October 2026. HTTP/3 is defined by IETF RFC 9114 and QUIC by RFC 9000. Whether any specific Offshore Hosting plan or server has HTTP/3 enabled is [TO BE CONFIRMED] — check your plan’s documentation or ask support rather than assuming.

    Related guides

    Related service: Hosting plans

  • Docker and Containers on a VPS: A Practical Introduction

    Key takeaways

    • A container packages an application with its dependencies; it shares the host kernel, which makes it far lighter than a virtual machine but less deeply isolated.
    • Containers shine for repeatable deployments, several applications on one VPS, and self-hosted software that ships official images.
    • Data belongs in volumes, never only inside a container; Compose files describe and document the whole setup.
    • Updates, restart policies and backups remain your responsibility — Docker changes how you do them, not whether they happen.

    Ask anyone who runs software on servers what problem Docker solved and you will hear the same sentence: it worked on my machine. An application needs a specific runtime, specific libraries and specific settings; a server provides almost-but-not-quite those things; the gap is where deployments go to die. Containers close the gap by packaging the application together with its dependencies into one unit that runs the same everywhere. This guide explains what containers are, how they differ from the virtual machines you already know from VPS hosting, when they genuinely help, and the basics of running them on a VPS.

    What a container is

    A container is a standardised package — an image — containing an application and everything it needs to run: its runtime, libraries and default configuration. When you start an image, you get a running container: the application, isolated from other containers and from most of the host, sharing the host operating system kernel rather than carrying its own. That sharing is the defining difference from a virtual machine. A VM emulates a whole computer, with its own kernel and operating system, which is why a VPS can run a different OS from its host. A container is lighter: no guest operating system, startup in seconds rather than minutes, and far less memory overhead. The trade is isolation depth — containers share a kernel, so they are separated less absolutely than VMs. In practice, the common pattern is both together: containers running inside a VPS, getting the VPS strong boundary from the outside world and containers convenience inside it. Docker is the tooling that made containers mainstream: the Docker Engine runs them, Docker Hub and other registries distribute images, and Docker Compose describes multi-container applications in a single file.

    When containers help

    Repeatable deployments. The image that ran in testing is byte-for-byte the image that runs in production. Environment drift — the slow divergence between servers — largely disappears.

    Several applications on one VPS. Each app lives in its own container with its own dependencies. Two applications needing different versions of the same runtime stop being a conflict and become two lines in a file.

    Easy updates and rollbacks. Updating becomes pulling a newer image and restarting the container; rolling back is starting the previous image. Compare that with unpicking a manual install.

    Self-hosted software. Many open-source applications — automation tools like n8n, CRMs, analytics, wikis — publish official images and a Compose file as their recommended install method. Containers are often simply the intended way to run modern self-hosted software.

    Containers help less when you run one simple application that a hosting panel already manages well — a single WordPress site gains little — or when an application needs deep access to hardware or a different kernel. They are a tool, not a virtue.

    The basics on a VPS

    The shape of working with Docker is small enough to state plainly:

    1. Install Docker Engine from Docker official repository for your distribution, and add your user to the docker group so you are not running everything as root. Note that docker-group membership is effectively root-level power — treat it that way.
    2. Run something. docker run -d --name hello -p 8080:80 nginx pulls the nginx web server image, starts it detached, and maps the server port 8080 to the container port 80. Your site answers on port 8080.
    3. Keep data in volumes. Containers are disposable; their internal filesystems vanish when they are removed. Anything that must survive — databases, uploads, configuration — belongs in a Docker volume or a bound directory on the host. This is the single most important habit: data in volumes, containers treated as replaceable.
    4. Use Compose for anything real. A docker-compose.yml file describes your services, images, ports, volumes and environment in one place: 
      services:
  app:
    image: example/app:latest
    restart: unless-stopped
    ports:
      - 8080:80
    volumes:
      - appdata:/data
volumes:
  appdata:

      docker compose up -d starts the whole arrangement; the file itself becomes the documentation of what runs and how.

    5. Put HTTPS in front. Containers usually serve plain HTTP on their ports. The common pattern is one reverse proxy — itself often a container — that terminates HTTPS with proper certificates and forwards to each application. Expose only the proxy ports on the firewall, not every application.

    Running them safely and steadily

    Restart policies. Set restart: unless-stopped so containers come back after a reboot or a crash, rather than discovering on Monday that a Friday restart stopped everything.

    Updates are your job. A container freezes its software at image build time — including its vulnerabilities. Update deliberately: pull the new image, restart, verify. Pin versions rather than floating on latest for anything you care about, so an update never arrives unplanned.

    Resource sense. Containers share the VPS CPU and memory. On a small server, set memory limits for hungry applications so one container cannot starve the rest — and size the VPS for the sum of what runs on it.

    Backups mean volumes. Back up the volumes and your Compose files and configuration, not the containers themselves. Restoring is then: reinstall Docker, restore volumes, docker compose up -d.

    Networking and ports, briefly

    The piece beginners most often get wrong is exposure. A container ports are not public just because it is running: they reach the internet only when you publish them with a port mapping (the 8080:80 above) or the container shares the host network. That is a useful safety property — a database container with no published port is reachable by your other containers and by nothing else. Containers on the same Compose project can reach each other by service name, as if each had its own little hostname: the application connects to a database at db:5432 without knowing or caring which container that is today. Combined with the reverse-proxy pattern from the previous section — one container publishing ports 80 and 443, everything else unpublished — a VPS running a handful of applications exposes exactly two ports to the world, and each application stays isolated behind them. That is a tidy security posture for very little machinery, and it is a large part of why containers won over installing everything directly on the host.

    Your first week with containers

    A sensible order for learning on a real VPS: install Docker, run the nginx example above until the port mapping makes sense, then convert that single container into a Compose file and feel the difference. Next, containerise something you actually use — a small self-hosted tool is ideal — with its data in a volume, and practise the full cycle once while nothing depends on it: update the image, restart, break it deliberately, restore from your backup of the volume. Those four operations are ninety percent of life with containers. Orchestration tools such as Kubernetes exist for fleets of servers and teams; on a single VPS they are almost always more machinery than the problem needs, and Compose remains the right-sized tool.

    The bottom line

    Docker on a VPS is the standard way to run modern self-hosted software for good reasons: identical environments, tidy separation between applications, painless updates and rollbacks. Learn four habits — volumes for data, Compose for structure, a reverse proxy for HTTPS, deliberate updates — and a single VPS becomes a clean, well-documented home for everything you self-host. Skip them, and containers just give old messes a new place to live.

    Reviewed 25 October 2026. Commands shown are the standard Docker Engine and Compose syntax; consult Docker current documentation for installation steps for your operating system version. Offshore Hosting plan details are as published on the VPS Hosting page; anything not stated there is [TO BE CONFIRMED].

    Related guides

    Related service: VPS Hosting

  • cPanel vs Plesk vs DirectAdmin: An Honest Comparison

    Key takeaways

    • All three panels manage the same core jobs; they differ in interface, pricing model, operating systems and weight.
    • cPanel charges per account and has the largest ecosystem; Plesk runs on Windows too and editions are priced by domains; DirectAdmin is the lightest and usually the cheapest to license.
    • Need Windows or heavy WordPress management: Plesk. Need maximum compatibility and reseller depth: cPanel. Need lean and economical: DirectAdmin.
    • The host behind the panel matters more than the panel itself.

    Every shared hosting account and most VPS setups are operated through a control panel: the web interface that handles websites, email, databases, DNS, SSL certificates and backups. Three panels dominate — cPanel, Plesk and DirectAdmin. They do the same job with different philosophies, different pricing models and different weights. This comparison covers the differences that matter, without pretending one is best for everyone.

    What a control panel actually does

    A panel is an administration layer over the server’s services. Instead of editing configuration files for the web server, mail server and DNS by hand, you click: add a domain, create a mailbox, issue a certificate, restore a backup. Panels also separate users — a hosting account holder sees only their own sites — which is what makes shared and reseller hosting practical. If you run a VPS alone and are comfortable on the command line, a panel is optional. The moment other people need access, it stops being optional.

    cPanel: the incumbent

    cPanel (with WHM, its server-level companion) is the most widely used panel in shared hosting, particularly in North America. Most tutorials, host documentation and support answers on the internet assume cPanel, which is a genuine advantage when you are learning or troubleshooting at midnight.

    • Interface. A dense, icon-and-list interface that long-time users navigate by memory. WHM handles server and reseller administration; cPanel handles individual accounts.
    • Operating systems. Linux only. There is no Windows version.
    • Pricing model. Per-account licensing: the licence cost scales with the number of hosting accounts on the server, in tiers. For a server with hundreds of small accounts, this is the model to cost carefully — it changed the economics of budget shared hosting when it was introduced, and it is the main reason many hosts now offer alternatives.
    • Features. The deepest ecosystem of the three: the widest range of third-party plugins (backup tools, security suites, installers), mature reseller tooling, and built-in transfer tools from other panels.

    Plesk: the cross-platform organiser

    Plesk is the panel most associated with Windows hosting, and the only one of the three that runs on both Linux and Windows servers. It is also popular with agencies and WordPress-focused hosts.

    • Interface. A cleaner, more modern interface organised around websites rather than server functions. Its WordPress Toolkit — centralised updates, staging and cloning for many WordPress sites — is its signature feature and a real time-saver for people managing WordPress at volume.
    • Operating systems. Linux and Windows.
    • Pricing model. Edition-based: licences are sold in editions limited mainly by the number of domains (a small-domain edition for personal servers, a mid edition for professionals, and an unlimited edition aimed at hosts). Cost does not rise per account the way cPanel’s does, which makes budgeting predictable.
    • Features. Strong built-in toolkit approach — WordPress management, a capable extension catalogue, and integrated security and repair tools. Docker support is available through an extension on Linux.

    DirectAdmin: the light, economical option

    DirectAdmin is the oldest kind of panel in spirit: deliberately simple, fast and light on server resources. It has grown steadily as hosts look for a cPanel alternative with calmer licensing.

    • Interface. Plain and functional. It does everything essential — domains, email, databases, DNS, SSL, backups, reseller levels — with less visual polish than its rivals. Most users adapt quickly; there is simply less to learn.
    • Operating systems. Linux only.
    • Pricing model. Licence tiers by account/domain allowances, with an unlimited tier, and historically the lowest licence cost of the three — including, at times, lifetime licence options. Because cost does not climb steeply with account count, it suits budget shared hosting and small resellers.
    • Features. Covers the core thoroughly and supports the common ecosystem tools (for example Softaculous and JetBackup), but the third-party plugin ecosystem is smaller than cPanel’s. Its lightness is itself a feature: it runs comfortably on small VPS plans where heavier panels eat into memory.

    Side by side

    Question cPanel Plesk DirectAdmin
    Operating systems Linux Linux and Windows Linux
    Licence model Per account, tiered Per server, by domain edition Per server, tiered, economical
    Interface style Dense, familiar, huge tutorial base Modern, website-centred Plain, minimal
    Standout strength Ecosystem and reseller depth WordPress Toolkit, Windows support Low resource use, low cost
    Typical user Shared/reseller hosts, traditional setups Agencies, WordPress fleets, Windows sites Budget hosts, small VPS, minimalists

    How to choose

    Choose cPanel if you are buying shared or reseller hosting and want the panel most tutorials describe, or if you need its specific plugin ecosystem and reseller tooling. On a VPS, price the licence against your account count first.

    Choose Plesk if you need Windows hosting, manage many WordPress sites and want the WordPress Toolkit, or prefer a per-server licence whose cost you can predict regardless of account numbers.

    Choose DirectAdmin if licence cost and server resources matter most — a small VPS, a budget reseller business, or a host whose per-account cPanel costs no longer add up — and you do not need panel-specific extras.

    Two practical notes apply to all three. First, migration between panels is possible — all offer import tools — but it is never a five-minute job with email, DNS and edge cases, so choose as if you will stay for a while. Second, the panel is not the hosting: a good host on any of these beats a bad host on your favourite panel, every time.

    Resource use and server fit

    Panels themselves consume resources, and on a small VPS the difference is visible. DirectAdmin is the lightest of the three — it was designed to run on modest hardware and still leaves most of a small server for the websites themselves. cPanel and WHM together expect a reasonably specified server, and Plesk sits in a similar range, varying with which of its components and extensions you enable. None of this matters on a large dedicated server; on a 1–2 GB RAM VPS it can decide whether the panel’s own services crowd out your applications.

    There is also the question of what the panel must coexist with. If the server’s real job is one demanding application and the panel is only there so a non-technical colleague can add an email account, the lightest panel wins. If the server’s job is hosting many customers, the panel is the product — and the ecosystem and reseller tooling arguments outweigh a few hundred megabytes.

    The bottom line

    There is no wrong panel here — there are wrong matches. Price cPanel by your account count, Plesk by your domain count and platform needs, and DirectAdmin by how lean you want the server to run. Then judge the provider offering it: support, backups and honesty about limits will decide your experience long after you have learned where the buttons are. All three panels are sold as server licences; compare the editions before you buy a server to match.

    Reviewed 25 October 2026. Panel features and licence models change over time; verify the current edition structure with the vendor or licence seller before relying on it. Offshore Hosting licence prices and availability are shown on the Server Licences pages of this site; anything not shown there is [TO BE CONFIRMED].

    Related guides

    Related service: Server Licences

  • Cloud Hosting vs VPS: The Real Differences

    Key takeaways

    • Most VPS plans already run on cloud infrastructure; the real choice is fixed-size simplicity versus elastic, usage-billed platforms.
    • A VPS gives a predictable bill and one server to understand; cloud gives granular scaling, better failure behaviour and a catalogue of managed services — at the cost of complexity and variable bills.
    • Spiky traffic, strict uptime needs and multi-region deployments favour cloud; steady workloads and small teams favour a VPS.
    • Judge any plan by where it runs, what happens when hardware fails, and what you are actually billed for — not by its label.

    Few hosting comparisons are muddier than this one, because the terms overlap: a VPS is a virtual server, cloud hosting is a way of running services across a pool of machines — and most VPS plans you can buy today are, underneath, instances on someone’s cloud. So the honest comparison is not between two technologies but between two ways of buying and running a server: a fixed-size virtual server at a fixed price, or an elastic platform where resources, redundancy and billing flex with usage. This guide separates the differences that are real from the ones that are only labels.

    What each term usually means

    A VPS is one virtual server with a defined specification — so many vCPUs, so much RAM and storage — for a fixed recurring price. It behaves like a small dedicated machine: you install an operating system, run your stack, and the specification changes only when you upgrade or downgrade the plan.

    Cloud hosting, as sold by cloud platforms and cloud-labelled hosting plans, spreads your workload across a pool of physical machines. Storage is typically network-based and replicated, instances can be resized, cloned or replaced quickly, and the surrounding catalogue — load balancers, managed databases, object storage — is part of the offer. Billing commonly follows usage for at least some components: instance hours, storage consumed, data transferred out.

    The differences that are real

    Scaling. A VPS scales in steps: when you outgrow it, you change plan, usually with a resize and a reboot. Cloud platforms scale in gradients — add instances behind a load balancer, grow storage independently, automate the whole thing. If your traffic is steady, steps are fine. If it swings wildly — a sale, a viral post, a seasonal peak — gradients earn their complexity.

    Failure behaviour. A VPS lives on one physical machine; if that host fails, your server is down until it is repaired or restored elsewhere. Cloud infrastructure is designed so a host failure is a smaller event: instances can restart on other hardware and replicated storage survives. How much of that design your particular cloud plan actually includes is a question to ask, not assume — the label alone guarantees nothing.

    Billing predictability. A VPS bill is knowable in advance, to the cent. Cloud bills vary: data transfer out (egress), storage operations and add-on services accumulate, and a misconfigured or suddenly popular application can produce a bill nobody budgeted for. Alerts and caps exist on serious platforms; setting them is your job.

    Complexity. A VPS is one server to understand, secure and back up. A cloud deployment is an architecture: networks, security groups, managed services and their interactions. That power is real, and so is the expertise it assumes. Many a small business has paid cloud prices to run, in effect, one small server — badly, because the platform’s defaults expected an engineer.

    Performance character. A VPS’s resources are reserved and consistent. Cloud instances vary by family and generation, and network storage behaves differently from local NVMe — sometimes imperceptibly, sometimes not. Benchmark your actual workload rather than trusting tier names.

    When each wins

    A VPS wins for the majority of real workloads: websites and stores with fairly predictable traffic, self-hosted applications, CRM and automation servers, development environments — anything where one well-sized server does the job and a predictable bill matters. It is also the better learning tool: one machine, fully understood.

    Cloud hosting wins when traffic is genuinely spiky or growing unpredictably, when downtime during a host failure is unacceptable, when you need the surrounding managed services (a database someone else patches and backs up, object storage, a load balancer) more than you need a server, or when you deploy across several regions at once.

    A dedicated server still wins some of these arguments outright — sustained heavy workloads, strict performance consistency — which is why the VPS-versus-dedicated question is worth asking separately.

    How to decide

    1. Plot your traffic honestly. Flat or gently growing: VPS. Violently spiky: consider cloud.
    2. Price your real month, not the headline. Model the cloud option with your actual storage, transfer and add-ons. Compare it with the VPS price for the size you need. If the totals are close, prefer the simpler thing.
    3. Ask what failure costs you. If an hour down during a host repair is an inconvenience, a VPS with good backups is a rational choice. If it is a crisis, pay for redundancy — wherever you buy it.
    4. Count the expertise in the room. Cloud platforms reward engineering time. If nobody will spend it, a managed VPS or a managed cloud plan — with the management scope written down — is the honest option.
    5. Beware the label. Whatever the plan is called, ask three questions: where does my server actually run, what happens when that hardware fails, and what exactly am I billed for? The answers describe your hosting better than the category name does.

    The middle options

    The industry sells plenty of products between the two poles, and knowing they exist stops you forcing a bad fit. A VDS (virtual dedicated server) is a VPS with resources guaranteed at a stricter level — dedicated CPU capacity rather than a fair share — for workloads that find ordinary VPS performance too variable but do not need a whole machine. Managed cloud wraps a cloud platform in a provider’s administration: you get the platform’s elasticity while someone else handles its configuration and patching, at a price that reflects both. And many “cloud hosting” plans from conventional hosts are, on inspection, a VPS with hourly billing and a resize button — which may be exactly what you want, provided you buy it for what it is rather than for the word on the page.

    The practical lesson: buy properties, not categories. Reserved performance, failure behaviour, billing shape and management scope are properties you can ask about and get in writing. “Cloud” and “VPS” are labels that each contain multitudes.

    A worked way to think about it

    Strip the labels away and ask what your workload looks like as a graph. A business website’s graph is a gentle hill: mornings busier than nights, growth measured in months. One fixed server, sized for the hill’s top with headroom, plus good backups, is the rational purchase — elasticity would solve a problem the graph does not show. An online store’s graph has cliffs: a promotion, a mention, a seasonal rush, then a drop. There, the ability to add capacity for a weekend — or hosting that absorbs the spike without a plan change and a reboot — can pay for a year of platform complexity in a single saved sale day. The graph, not the fashion, should make this decision; if you do not know your graph, start with the VPS, measure for a few months, and revisit with evidence.

    The bottom line

    Cloud versus VPS is not a technology contest; it is a decision about elasticity and complexity. Buy the fixed server when your workload is steady and your team is small — which describes most websites and business applications — and buy the platform when scaling, redundancy or managed services solve a problem you actually have. And whatever the brochure calls it, ask where your server runs, what failure looks like, and what the bill includes. Providers who answer those three plainly are the ones worth hosting with.

    Reviewed 25 October 2026. Offshore Hosting sells VPS, VDS and dedicated plans as published on this site; whether a cloud-labelled product will be offered is [TO BE CONFIRMED]. Cloud platform billing models described are the general industry pattern — verify the specific model of any platform you consider.

    Related guides

    Related service: Hosting plans

  • Business Email Hosting: Professional Email on Your Own Domain

    Key takeaways

    • Business email means mailboxes on your own domain: portable, controllable, and yours as long as you renew the domain.
    • It needs a domain, correct MX records, and SPF, DKIM and DMARC authentication — without those, deliverability suffers no matter who hosts you.
    • Hosting-plan mailboxes are simple and cheap; a dedicated email service costs per mailbox but separates your email’s fate from your website’s.
    • Judge offers on mailbox storage, filtering, app support and exit options, not on the headline mailbox count.

    There is a small moment of judgement in every business exchange: the reply that comes from a free webmail address instead of the company’s own domain. It is unfair, but it is real — and it is only the visible part of the difference. Email on your own domain is also easier to keep when you change providers, easier to extend to new staff, and impossible for a free-mail provider to take away. This guide explains what business email hosting actually involves and how to choose between the two ways of getting it.

    What business email hosting is

    Business email hosting is a service that runs mailboxes for your domain: addresses like [email protected], with storage, sending and receiving, spam filtering, and access through webmail, desktop clients and phones. The domain is the anchor. Whoever hosts the mail, the addresses belong to your domain — and the domain belongs to you.

    That separation matters. Your website host, your email host and your domain registrar can be three different providers, and you can change any one of them without losing your addresses, as long as the DNS records are managed properly.

    How it differs from free webmail

    • Identity. Your domain on every message, instead of advertising a free-mail brand.
    • Control. You create and remove mailboxes as staff join and leave, set mailbox sizes, and keep the address when someone departs. With personal free accounts, a departing employee takes the address — and the password resets — with them.
    • Continuity. A free-mail account can be closed under the provider’s terms and its address can never be re-registered by you. Your domain renews as long as you renew it.
    • Deliverability tools. On your own domain you publish the authentication records — SPF, DKIM and DMARC — that tell receiving servers your mail is genuine. On a free address, you inherit whatever reputation that shared domain has, good and bad.
    • Support and terms. Business services come with business terms. Free webmail comes with a consumer account and consumer remedies.

    What it needs to work

    A domain you control, with access to its DNS. Everything else hangs off this.

    The right DNS records. MX records tell the internet which servers accept your mail. SPF, DKIM and DMARC records authenticate your sending. These are covered step by step in our guide to setting up SPF, DKIM and DMARC — they are not optional extras: without them, a growing share of your mail lands in spam or is rejected outright.

    Enough storage, honestly counted. Email accumulates. A mailbox that is generous at signup can be full within a couple of years once attachments pile up. Check the per-mailbox limit, whether it can grow, and what archiving or downloading old mail looks like.

    Access your people will actually use. Webmail for occasional access, plus proper support for mail apps (IMAP for syncing across devices) and, where needed, calendar and contacts sync. Ask what is included rather than assuming.

    Spam and virus filtering on the service, and a clear policy for what happens to caught mail — a filter that silently eats a customer’s order enquiry is worse than spam.

    The two ways to get it

    Mailboxes on your hosting account. Many hosting plans include email for your domain at no extra line item. This is simple and cheap, and for a small business with modest mail volume it works well. The honest limitations: mailbox storage usually shares your hosting space, sending reputation is shared with the server’s other customers, and if the website’s server has a bad day, your email has the same bad day.

    A dedicated email service. A separate provider whose only job is email. You point your MX records at them and leave your website where it is. This costs a per-mailbox fee, and in return you typically get larger mailboxes, stronger filtering, better sending reputation, and email that stays up when your website does not. For businesses where email is operationally critical — orders, support, invoicing — that independence is the point.

    Neither is universally right. A one-person business with light email is well served by hosting mailboxes. A ten-person firm living in its inbox should usually separate email onto a dedicated service. What both options share: your domain, your DNS records, your addresses — portable either way.

    Moving email without losing it

    Email is the part of a migration people fear, and the fear is justified only when mail is treated as an afterthought. The safe pattern: set up the new mailboxes first, copy the existing mail across (mailbox sync tools do this over IMAP), switch the MX records only when the new service is ready, and keep the old mailboxes alive until every device has picked up the new settings. Our guide to transferring a domain without disrupting email walks through the same discipline for domain moves.

    Day-to-day practices that keep business email working

    Protect the mailboxes themselves. Email is the master key to a business: password resets for banking, hosting and social accounts all land in the inbox. Strong unique passwords and two-factor authentication on mailboxes — especially the ones used for account recovery — are not optional hygiene.

    Use aliases deliberately. Addresses like sales@ and support@ are usually aliases or shared mailboxes rather than one person’s account. Set them up that way, so enquiries reach whoever is on duty and survive staff changes, instead of living in one employee’s personal mailbox.

    Decide retention before you need it. Who can read a departed employee’s mailbox, how long mail is kept, and where the archive lives are questions to answer in calm times. During a dispute or an incident is the wrong moment to improvise them.

    Watch the domain, not just the mailbox. Almost every catastrophic business email failure is actually a domain failure — an expired domain, a registrar account in a former employee’s name, DNS changed without noting the old records. Keep the domain registered to the business, with renewal reminders reaching more than one person.

    What it costs, honestly framed

    Business email is rarely expensive next to a business’s other tools, but the pricing shapes differ enough to compare carelessly. Hosting-plan mailboxes are usually bundled — the cost hides in the hosting plan and the storage limit. Dedicated services charge per mailbox per month, which scales visibly as the team grows and tempts businesses to share mailboxes they should not share. The real cost either way is not the licence line; it is the hour email spends down, the order that sat in a spam folder, or the account a former employee still controls. Judge offers against those costs, and the per-mailbox fee of a proper service usually looks like what it is: cheap insurance for the channel your customers actually use.

    The bottom line

    Email on your own domain is one of the cheapest credibility upgrades a business can make, and one of the easiest to keep: set the DNS up properly, authenticate your sending, and choose between hosting mailboxes and a dedicated service based on how much your business would hurt if email stopped for a day. Get those decisions right and moving provider later — for the website, the email, or both — becomes a routine job instead of a crisis.

    Reviewed 25 October 2026. Whether Offshore Hosting plans include email mailboxes, and any mailbox limits, are [TO BE CONFIRMED] — this article does not state them. Deliverability also depends on your domain’s history and sending behaviour, which no host can fully control.

    Related guides

    Related service: Solutions

  • AI and GPU Hosting: What a GPU Server Is Actually For

    Key takeaways

    • A GPU does massively parallel maths; AI training and inference, rendering, transcoding and some simulations have that shape — websites and databases do not.
    • For AI work, the GPU model and its VRAM decide what you can run; "GPU included" without a named card is not a specification.
    • Check the whole server — CPU, RAM, NVMe storage, bandwidth — plus whether the GPU is dedicated or a shared slice.
    • If AI runs in a vendor’s cloud, your server does not need a GPU at all.

    A graphics processing unit was built to draw game worlds: thousands of small cores doing the same simple maths on huge amounts of data at once. It turned out that exactly that shape of work — massive, repetitive calculation — is also what training and running AI models, rendering 3D scenes, and processing video require. GPU hosting is simply renting a server with one or more of those processors attached. This guide explains which workloads genuinely benefit, which do not, and what to verify before paying GPU prices.

    GPU versus CPU, in one paragraph

    A modern server CPU has a modest number of powerful cores, each good at varied, sequential work — running your operating system, your database logic, your application code. A GPU has thousands of simpler cores that excel when the same operation applies to millions of data points at once, as in the matrix mathematics inside a neural network. Neither replaces the other: a GPU server still has a CPU running everything else. The question is never “GPU or CPU” but “does my workload have the parallel shape a GPU rewards?”

    Who actually needs a GPU server

    Training machine-learning models. Training is the most parallel workload there is, and the one where a suitable GPU turns days of CPU time into hours. If you are training or fine-tuning models on your own data regularly, this is the clearest case.

    Running inference at volume. Serving a trained model — answering questions with a language model, transcribing audio, classifying images — also maps well to GPUs, especially when many requests arrive at once or responses must be fast. A single occasional query does not need a GPU; a service answering all day does.

    Rendering and video work. 3D rendering farms, video transcoding pipelines and some scientific simulations (weather, molecular, financial modelling) are built around GPU acceleration, and the software in those fields says so explicitly.

    Development and learning. A rented GPU server is also how individuals learn this stack without buying hardware: run the frameworks, break things, shut it down.

    Who does not need one

    Websites — including busy WordPress and WooCommerce sites — do not use a GPU in any meaningful way. Neither do databases, email, game-independent business applications, automation tools like n8n, or ordinary APIs. If your workload is a website or a business application, spend the money on CPU cores, RAM, fast NVMe storage and caching instead; those are the levers that move it. “AI-powered” in a product’s marketing does not change this: if the AI runs in the vendor’s cloud, your server never touches it.

    What to check before buying

    • The GPU model and its memory (VRAM). For AI work, VRAM is usually the binding constraint: a model must fit in it, along with its working data. A newer GPU with too little memory for your model is worse than an older one with enough. Check your framework’s stated requirements against the specific card offered — “GPU included” without a model name is not a specification.
    • The software stack. AI frameworks are built primarily around NVIDIA’s CUDA platform; if your work depends on CUDA, confirm the GPU and driver versions support the framework versions you plan to run. Other ecosystems exist, but check your exact tools rather than assuming compatibility.
    • Dedicated or shared. A dedicated server gives you the whole GPU. Virtualised GPU offerings share or partition a card between customers, which can be a sensible cost saving for lighter work — but know which you are buying and what slice of the card is actually yours.
    • The rest of the server. A fast GPU fed by a weak CPU, little RAM or slow storage spends its life waiting. Check the balance: enough RAM to hold your datasets, NVMe storage to load them quickly.
    • Data movement. Training data and models are large. Check the server’s bandwidth allocation and transfer limits against how much data you will move in and out — a cheap GPU with expensive or capped transfer can invert the maths.
    • Billing shape. GPU servers cost substantially more than CPU servers of similar size. If your workload is bursty — a training run twice a month — a server you can start and stop, or rent for shorter terms, may beat a monthly commitment. Confirm what the billing unit actually is.

    A note on expectations

    A GPU accelerates the work it suits; it does not make a badly structured project succeed, and small models on small data often run perfectly well on a CPU. The honest test before renting: run your workload once, measure where the time goes, and rent a GPU only when the parallel part of the job is demonstrably the bottleneck.

    Dedicated GPU server, cloud GPU, or your own hardware

    The same GPU can be rented three ways, and the right one depends on how steady the work is. A dedicated GPU server — a physical machine with the card installed — suits continuous workloads: an inference service answering all day, a render node in constant use. You get the whole card, predictable performance, and a fixed monthly cost to budget against.

    Cloud GPU instances rent the same hardware by the hour or minute. For bursty work — training runs, experiments, deadline rendering — that shape is usually cheaper despite a higher hourly rate, because idle hours cost nothing. The responsibilities shift, though: you are assembling the environment on a cloud platform, watching a meter, and remembering that storage and data transfer bill separately.

    Buying your own hardware only makes sense with sustained, predictable demand and someone to maintain it; the card’s purchase price is the beginning of the cost, not the end — power, cooling, and eventual replacement all belong in the comparison. For most teams reading a hosting guide, renting first and measuring real usage is the order that avoids an expensive paperweight.

    One more check whichever route you choose: confirm the card is a data-centre model licensed for server use. Consumer gaming cards are sometimes offered cheaply in servers, but their drivers and licence terms are written for desktops, and their cooling assumes a gaming case, not a rack. A suspiciously cheap GPU server deserves that question before any other.

    How the work is developing

    Two trends are worth knowing before you commit budget. First, smaller models and better optimisation keep reducing the hardware that useful AI work needs: tasks that recently required a large card increasingly run acceptably on a modest one, or even on a modern CPU. Renting short-term and re-measuring beats buying for last year’s requirements. Second, inference — serving models — is becoming the everyday workload, and it rewards a different balance than training: enough VRAM for the model, fast responses under many simultaneous requests, and uptime over raw peak speed. If your plan is a service rather than an experiment, evaluate the server as you would any production host: monitoring, backups of your model files and data, and a provider whose support answers when the service is down, not only when you are buying.

    The bottom line

    GPU hosting is a specialist tool that is transformative for the workloads it fits and a waste of money for everything else. Name your workload, confirm it is parallel work your software accelerates on a GPU, size the card by its memory, and check the server around it. Do that, and a GPU server is a straightforward rental. Skip it, and you have bought the most expensive way to run a workload that never touches the card.

    Reviewed 25 October 2026. Whether Offshore Hosting will offer GPU servers, and with which hardware, is [TO BE CONFIRMED] — this article does not state availability, models or prices. Framework and driver compatibility changes quickly; verify against your software’s current documentation.

    Related guides

    Related service: Dedicated Hosting

  • A Website Launch Checklist for Domains, Hosting, and Security

    A Website Launch Checklist for Domains, Hosting, and Security

    A website launch fails in predictable ways: the domain points at the wrong server, the SSL certificate is missing, the contact form sends mail nowhere, or the site goes live with staging credentials still in place. None of these is hard to prevent. Each is hard to fix gracefully once visitors and search engines have seen the broken version.

    Use this checklist in order. Each section builds on the one before it, and the sequence is designed to prevent the most common failure: changing DNS before the site, the certificate, and the email are ready.

    Phase 1: Domain and hosting (1–2 weeks before launch)

    • Confirm domain ownership and access. You can sign in to the registrar, the domain is unlocked for management, and you know the renewal date. If the domain was bought by someone else — an agency, a former employee — transfer or confirm access now, not on launch day.
    • Confirm the hosting plan is provisioned. You can sign in to the control panel, the plan covers the site’s needs (storage, bandwidth, databases, email), and you know the renewal price and date. See our guide to comparing introductory and renewal hosting prices if the renewal terms are unclear.
    • Decide the canonical domain. Choose www or non-www (for example, www.example.com or example.com) and use it consistently everywhere. Set up a redirect from the other version so both work and only one is indexed.
    • Lower the DNS TTL. Reduce the time-to-live on your DNS records to around 5 minutes, 24–48 hours before the launch. This makes the DNS change propagate quickly and gives you a fast rollback if something goes wrong. Remember to raise the TTL back to a normal value (for example, a few hours) after launch.
    • Note the renewal dates for the domain, the hosting, and the SSL certificate in a shared calendar, with a reminder 30 days ahead.

    Phase 2: Build and content (before the cutover)

    • Proofread everything. Read every page on the live staging URL: text, prices, phone numbers, addresses, and links. Check images display correctly and have descriptive alt text.
    • Check navigation and links. Every menu item works, there are no broken internal links, and no link points to the staging domain. Search the site for the staging URL before launch.
    • Test on real devices. Check the site on a phone on mobile data, not only on desktop Wi-Fi, and in more than one browser. Confirm the mobile menu works, text does not overflow, and forms are usable on a small screen.
    • Set page titles and meta descriptions. Every important page needs a unique, relevant title and meta description. Confirm the heading structure is logical (one H1 per page, headings in order).
    • Check the sitemap and robots.txt. Confirm yourdomain.com/sitemap.xml and yourdomain.com/robots.txt return the expected content, and that staging restrictions such as noindex or password protection are removed before launch.
    • Set up analytics and Search Console. Install the analytics tracking code, verify it records visits on staging, and prepare to submit the sitemap to Google Search Console after launch. Set up Open Graph metadata so links shared on social media show the right title and image.

    Phase 3: Security and HTTPS

    • Enable SSL and force HTTPS. Confirm the certificate is active, the site loads on https:// with no browser warning, and all pages redirect from HTTP to HTTPS. See our guide to SSL certificates and HTTPS for the details and the common errors.
    • Check the certificate covers every hostname visitors will use, including www and any subdomains.
    • Remove development secrets. No API keys, passwords, or credentials in the code, in public files, in logs, or in screenshots. Production secrets should live in the hosting environment’s configuration, not in the repository.
    • Secure the admin area. Strong, unique passwords, two-factor authentication where available, and no default accounts. Restrict admin access by IP where practical.
    • Turn off error display in production. Errors should go to a log file, not to the browser.
    • Update everything. The CMS, the theme, plugins, and server software should be on supported versions before launch, not after. Check for known vulnerabilities in the components you use.
    • Review security headers where applicable, including content security policy, HSTS, and frame protections, if your hosting or application supports them.

    Phase 4: Email — do this before changing DNS

    Email is the part most launches break, because DNS and email routing are tightly connected. Do this before the cutover:

    • Create mailboxes and aliases for the addresses the business needs, and confirm each one can send and receive.
    • Check the MX records point at the right mail provider, and that they will not be disrupted by the DNS change. Review the A, AAAA, CNAME, MX, and TXT records together — changing the website’s A record should not accidentally remove the mail records.
    • Set up SPF, DKIM, and DMARC. Publish the records for every service that sends mail as your domain, starting DMARC in monitoring mode (p=none). Our guide to setting up SPF, DKIM, and DMARC walks through the order and the checks.
    • Test the website’s forms. Submit each form and confirm the notification arrives in the right inbox — not in spam, and not nowhere.

    Phase 5: Backups and the cutover

    • Take a full pre-launch backup of the old site if one exists — files and database — and store it outside the production environment. Take a backup of the new site too, before it goes live.
    • Confirm the backup can be restored. A backup you have never restored is a hope, not a backup. If your hosting offers a restore test or a staging restore, use it.
    • Run a final staging crawl for 404s, redirect chains, and template errors.
    • Perform the DNS swap. Point the domain at the new server, then verify from multiple networks or locations that the live URL resolves correctly and the site loads.
    • Verify SSL on the live domain as soon as DNS propagates, on the homepage and a few interior pages, with no mixed-content warnings.
    • Test the critical paths live: homepage, contact form, checkout or booking flow, login, and search — on desktop and on a phone.
    • Check redirects if you are replacing an old site: every important old URL should redirect to the right new URL, not to the homepage.

    Phase 6: After launch (first 24–72 hours)

    • Submit the sitemap to Google Search Console and request indexing for the homepage and the top priority pages.
    • Monitor analytics and error logs for the first day. A spike in 404s usually means a missed redirect; a drop in form submissions usually means a mail problem.
    • Monitor uptime from an external service, so you know about outages before your customers tell you.
    • Check email deliverability — send test messages to the major providers and confirm they arrive in the inbox.
    • Raise the DNS TTL back to its normal value now that the cutover is done.
    • Tell people. Announce the launch to customers and on your own channels, and confirm the announcement links point at the live domain.
    • Schedule a post-launch review after a week: analytics, Search Console coverage, form submissions, and any issues reported by visitors.

    Keep this checklist

    Save a copy of this checklist with your launch notes — what was checked, by whom, and when. The next launch, the next migration, or the next redesign will reuse most of it, and the record of what was verified is what turns a checklist into a process rather than a one-off scramble.

    Key takeaways

    • Work in order: domain and hosting, then content, then security, then email, then DNS.
    • Lower the DNS TTL 24–48 hours before the cutover so you can change and roll back quickly.
    • Set up email authentication and test forms before changing DNS, not after.
    • Take a backup before launch and confirm it can be restored.
    • Verify SSL, redirects, and critical paths on the live domain immediately after the cutover, then monitor for the first 72 hours.

    Sources

    • Paeveul, “The Launch Checklist We Actually Use” — https://www.paeveul.com/blog/launch-checklist-we-actually-use/index.html
    • JumboNIC, “How to Create a Website Launch Checklist for Clients” — https://www.jumbonic.com/how-to-create-a-website-launch-checklist-for-clients/
    • Trajectory Web Design, “Website Launch Checklist: The 2026 Guide for Going Live” — https://www.trajectorywebdesign.com/blog/website-launch-checklist/
    • Resort Web Marketing, “How to Set Up a Website and Email Launch Checklist for a New Business” — https://resortwebmarketing.com/website-email-launch-checklist-new-business/

    Sources

    • {‘title’: ‘The Launch Checklist We Actually Use’, ‘url’: ‘https://www.paeveul.com/blog/launch-checklist-we-actually-use/index.html’}
    • {‘title’: ‘How to Create a Website Launch Checklist for Clients’, ‘url’: ‘https://www.jumbonic.com/how-to-create-a-website-launch-checklist-for-clients/’}
    • {‘title’: ‘Website Launch Checklist: The 2026 Guide for Going Live’, ‘url’: ‘https://www.trajectorywebdesign.com/blog/website-launch-checklist/’}
    • {‘title’: ‘How to Set Up a Website and Email Launch Checklist for a New Business’, ‘url’: ‘https://resortwebmarketing.com/website-email-launch-checklist-new-business/’}

  • How to Compare Introductory and Renewal Hosting Prices

    How to Compare Introductory and Renewal Hosting Prices

    Almost every hosting comparison table makes the same mistake: it puts the advertised monthly price in a big column and lets you rank hosts by it. That advertised price is the one thing about hosting you can safely ignore — because in most cases it is the introductory price, available for the first term only. When that term ends, the price jumps, often by several hundred percent.

    The right comparison is not “what is the monthly price” but “what will I have paid after two or three years, including renewal?” This guide shows how to work that out, and what else to check before you buy.

    How introductory pricing works

    Shared hosting is typically sold on an introductory rate that applies to the first term only — usually one, two, or three years, paid upfront. When that term ends, the plan renews at the regular rate. The jump is often large: independent comparisons published in 2026 show introductory rates roughly doubling to quintupling at renewal, depending on the provider and plan. A plan advertised at a low monthly rate can renew at three to five times that figure.

    The mechanism is straightforward: the low first-term price is a customer-acquisition cost the provider recovers later. That is a legitimate business model, but it means the headline price is a promotion, not the price of the service.

    Two details make the comparison harder than it looks:

    • Term length changes the price. The lowest advertised monthly rate usually requires the longest prepay — often three or four years upfront. A one-year term at the same provider costs more per month. Always compare the same term length, and always note the total amount you will actually pay at checkout, not the monthly figure.
    • The renewal lands later than you think. If the introductory price requires a 24-month prepay, the jump lands in month 25, not month 13. That delay makes the renewal easy to forget — until the invoice arrives.

    The calculation that matters: total cost over 2–3 years

    For each host on your shortlist, work out the same number:

    Total cost = (introductory monthly rate × months in the first term) + (renewal monthly rate × months after renewal) + add-ons over the same period

    A simple two-year version:

    • Year 1: promo price × 12 months
    • Year 2: renewal price × 12 months
    • Real 2-year cost = the sum

    Do this for three years as well if you expect to keep the site that long, because the renewal rate dominates the total once the first term is over. Two hosts that look far apart on headline price often end up within a small amount of each other over three years — the one with the higher entry price but the smaller renewal increase can be cheaper overall.

    Worked example (no real prices are used here — always take the current intro and renewal rates from the provider’s own pricing page, plug them into the formula above, and compare the totals):

    • Host A — low intro, high renewal. A low first-year rate with a large jump at renewal can look cheapest on the headline, yet cost the most over three years once the renewal rate applies for two of those years.
    • Host B — flat rate, no intro discount. A host with no discount and the same rate every year can look “expensive” at first glance, yet cost less over three years than a discounted host whose renewal rate is much higher.
    • Host C — very low intro locked for three years. The cheapest for the first three years, but the most expensive afterwards if its renewal rate is the highest of the three.

    Which one is right depends on how long you plan to stay, and that is a decision you should make consciously, not discover at renewal.

    What else changes the bill

    The renewal rate is the biggest factor, but it is not the only one. Check each of these on the pricing and checkout pages:

    • Add-ons that are free for the first year only. Daily backups, SSL certificates, security scans, and dedicated IPs are sometimes included in year one and charged afterwards. Basic SSL is now commonly free via Let’s Encrypt, but backups and security tools often are not. A few dollars a month in add-ons can add up to more than the hosting itself.
    • Domain renewal. A free domain for the first year is a common offer; the domain renews at the regular rate afterwards, and that rate varies by extension. Check it.
    • Email. Some plans charge separately for email storage or for a number of mailboxes beyond a small allowance.
    • Migration and setup fees. Most providers offer free migration for new customers; check whether it is genuinely included for your plan, and whether there is a time limit to claim it.
    • Resource limits and upgrade pressure. A cheap plan with tight storage or visitor limits may force an upgrade sooner than a slightly more expensive plan with generous limits. Read the resource limits, not just the price.
    • Money-back guarantee. A 30-day guarantee is common, but check what it covers — it usually covers hosting, not domains or add-ons — and whether the refund is automatic or requires a request.

    Flat pricing vs introductory pricing

    Some providers charge the same rate in month one and month twenty-five — no introductory discount, no renewal jump. Their headline price looks higher in a comparison table, and their three-year total is often lower or comparable. There is no universally right model: an introductory deal can be good value if you plan to move or renegotiate, and flat pricing is simpler to budget for if you plan to stay. The mistake is comparing a promo price with a list price as if they were the same thing.

    How to read a pricing page like a buyer

    1. Find the renewal price on the pricing page itself — it is usually in small print under the headline rate, or on the checkout page. If you cannot find it, ask support in writing before buying.
    2. Note the term length the headline rate requires, and the total amount due at checkout.
    3. Work out the 2-year and 3-year totals for every host on your shortlist, including add-ons.
    4. Check whether the renewal rate is written into the terms of service, or whether it can change. A rate written into the terms is a commitment; a rate on a pricing page can be changed.
    5. Set a calendar reminder for 30 days before renewal, so the renewal invoice is never a surprise — and so you have time to move if the numbers no longer work.

    Also read the SLA alongside the price. A cheap plan with no uptime commitment and a vague renewal policy is a different product from a slightly more expensive plan with a defined SLA. Our guide to reading a hosting SLA and uptime claim explains how to judge that side of the deal.

    [TO BE CONFIRMED: Offshore Hosting’s introductory and renewal prices, term lengths, included add-ons, and whether renewal rates are fixed in the terms — confirm before publishing any price claim for Offshore Hosting. This post states no Offshore Hosting prices.]

    Key takeaways

    • The advertised monthly price is usually the first-term price, not the real price. Compare total cost over two or three years.
    • Renewal rates commonly rise several-fold; the size of the jump matters more than the entry price.
    • Term length changes the monthly rate — compare like with like, and note the total due at checkout.
    • Add-ons, domain renewal, and resource limits all change the real cost.
    • Flat pricing looks more expensive in a table and is often cheaper over three years.
    • Find the renewal rate in writing before you buy, and set a reminder before it lands.

    Sources

    • Tabraiz Bukhari, “How to Choose a Web Host in 2026” — https://tabraizbukhari.com/best-web-hosting-platforms/
    • RealHostPrices, “Hosting Price Tracker” — https://realhostprices.com/
    • Daedalus Design, “UK Web Hosting Comparison 2026: Shared vs VPS vs AI Hosting” — https://daedalusdesign.co.uk/posts/uk-hosting-comparison.html
    • TopTierBlogHost, “cPanel Price Increase 2027: What It Means for Your Blog Hosting Bill” — https://www.toptierbloghost.com/cpanel-price-increase-2027/

    Sources

    • {‘title’: ‘How to Choose a Web Host in 2026’, ‘url’: ‘https://tabraizbukhari.com/best-web-hosting-platforms/’}
    • {‘title’: ‘Hosting Price Tracker’, ‘url’: ‘https://realhostprices.com/’}
    • {‘title’: ‘UK Web Hosting Comparison 2026: Shared vs VPS vs AI Hosting’, ‘url’: ‘https://daedalusdesign.co.uk/posts/uk-hosting-comparison.html’}
    • {‘title’: ‘cPanel Price Increase 2027: What It Means for Your Blog Hosting Bill’, ‘url’: ‘https://www.toptierbloghost.com/cpanel-price-increase-2027/’}