Contact

Ship · Deployment & hosting

App deployment and hosting services: servers set up, secured, deployed to and watched

App deployment and hosting services: servers or cloud set up and hardened, automated deploys with rollback, SSL, backups, monitoring and a runbook you keep. We put your web app, API and database on infrastructure in your own name, lock it down, and give it a release process where every deploy is checked page by page and can be undone in minutes. Then we watch it, and write down everything a future engineer needs to run it without us.

Get your hosting reviewedSee how we deploy

Updated

  • EdgeDNS · TLS · firewall
  • Proxynginx · redirects · limits
  • Web appbuilt in place
  • APIprocess-managed
  • Jobsschedules · queues
  • Databaseprivate · backed up
301
URLs on this website checked before and after its last security deploy
5
failed sign-ins in a day before a server bans the address
7
layers we harden, from the network edge to the data

At a glance

Where
Your own cloud account or a server you rent, in your company's name
Typical stack
Node.js APIs, Next.js sites, MongoDB, nginx and a process manager
Deploys
One app at a time, checked URL by URL, with a rollback ready
Security
Key-only sign-in, brute-force bans, locked-down secrets, TLS everywhere
Monitoring
Uptime and error alerts, answered in Indian working hours; no 24/7 on-call
You keep
Every account, every renewal and a written runbook
Last verified
4 November 2026

When you need this

Six warning lights that mean your hosting needs an owner

Hosting rarely fails all at once. It drifts: a manual step here, a password login left on there, a server nobody has looked at since launch. These are the signs we see when a product arrives with us, and each one has a fix that does not need a rebuild of the app.

  • It only runs where the developer left it

    The app was started by hand on a server, or still runs from someone's laptop. Nobody can say exactly which version is live, or how to start it again after the machine reboots for a security update.

    Fix: A process manager that restarts the app on failure and on boot, the live version tied to a commit, and the start-up written down.

  • Every deploy is a held breath

    Releasing means copying files and hoping. There is no record of what changed, no check that the site still works afterwards, and no way back except someone remembering the old files.

    Fix: A scripted deploy from a tagged commit, a check of every page after it, and a rollback that runs the same steps backwards.

  • The server and the code disagree

    Someone fixed something directly on the server. The repository no longer matches what is running, so the next proper deploy would quietly undo the fix and nobody would know why it came back.

    Fix: We stop, compare the server with the repository, commit or discard each difference with you, and only then deploy.

  • Thousands of failed logins in the logs

    Bots try passwords against any server with SSH open to the internet, all day and every day. If password login is on, it is only a matter of time before one of them guesses right.

    Fix: Key-only sign-in, a limit on tries per connection, and automatic bans for addresses that keep failing, growing longer for repeat offenders.

  • A security notice you cannot act on

    A framework advisory, a dependency audit full of red, or a runtime past its end of life. You know it matters, but upgrading feels riskier than waiting, so the notice sits in an inbox.

    Fix: Upgrades applied app by app on a copy first, checked against the live site URL by URL, then deployed with the old version kept ready.

  • Slow, full or surprising bills

    Pages slow down under load, the disk or memory fills, or the cloud bill grows every month and nobody can explain the line items or which of them can safely go.

    Fix: We measure what each process uses, right-size the server, and put alerts on disk, memory and spend before they become outages.

If two or more of these are lit, the first week with us is usually spent on the boring, high-value fixes: sign-in locked down, secrets protected, backups proven, and a deploy that can be undone. New features wait until the floor under them is solid. None of these fixes needs downtime you have not agreed to in advance.

What you get

A production setup drawn end to end, from the domain to the backups

Each box below is something we set up, test and hand over. The first two rows are the path a request takes from a phone or browser to your data and back. The last row is what keeps that path healthy when nobody is looking. For a small product all nine fit on one rented server; for a larger one they spread across a cloud account. The drawing stays the same either way, which is why we start every hosting job by drawing it for your product.

  1. D-01

    Domain and DNS

    Records for the site, the API and email, with one canonical address and the others redirecting to it, so search engines and users see a single site. Domain renewal stays in your name, with the date written down.

  2. D-02

    TLS certificates

    HTTPS on every address, certificates issued and renewed automatically, and plain HTTP redirected. An alert fires well before any certificate could expire, in case renewal ever fails.

  3. D-03

    Reverse proxy

    nginx in front of the apps: one entry point, compression, request size limits, security headers and clean redirects. Apps listen only on the machine itself, never directly on the internet.

  4. D-04

    App processes

    Each web app and API under a process manager that restarts it on failure and on reboot, with its runtime version pinned per app, so upgrading one never forces an upgrade on another.

  5. D-05

    Scheduled jobs

    Reminders, reports, renewals and clean-ups run on a schedule with logs you can read, not from a timer line nobody remembers adding. Each job is safe to run twice.

  6. D-06

    Database

    Reachable only from the apps that need it, never from the open internet, with separate users and the least rights each one needs, so a leaked app key cannot drop your data.

  7. D-07

    Backups and restore

    Scheduled backups kept away from the server they protect, and a restore we have actually run onto a spare copy, so a backup is known to work before the day you need it.

  8. D-08

    Monitoring and alerts

    Uptime checks on the pages and endpoints that matter, error logs collected in one place, and alerts on disk, memory and certificates before they turn into downtime.

  9. D-09

    Deploy and rollback

    A release process that builds, checks and switches one app at a time, and puts the previous version back on its own if anything it checks has changed.

What we watch, and what each alert means

A page or endpoint stops answering
The app has stopped, the proxy has lost it or the server is down. We check the process first, then the proxy, then the machine, and write down which it was.
Error rate rises after a release
Usually a change in the release itself. The rollback is the first move, the investigation the second, so users are not part of the debugging.
Disk passes a threshold
Logs or uploads growing without a limit. We rotate or move them before the disk fills, because a full disk stops databases from writing.
Memory climbs and stays up
A leak, or a process doing more than it should. We find which process, restart it safely if needed, and fix the cause in the code.
A certificate is near expiry
Automatic renewal has failed, usually because of a DNS or proxy change. We renew by hand and fix the reason.
Spend jumps on a third-party service
A retry loop, a bot, or a feature used far more than expected. We find the caller and cap it before the next invoice.

New to some of these words? Our glossary explains backups, secrets management, least privilege, scheduled jobs, error monitoring and CDNs in plain language.

How a release reaches production

Every deploy follows one path, and every step has a way back

This is the process we use on our own servers, including the one that serves this website. When we applied a framework security fix to countrydevs.com, all 301 URLs in its sitemap returned the same status before and after the deploy. If even one had changed, the release would have rolled itself back before anyone noticed.

The path starts after testing, not instead of it: features are checked on a staging copy and by a QA pass first. What the path adds is release management that does not depend on anyone's memory.

What “checked” means after a deploy

  • Every URL in the sitemap returns the same status code it returned before the release: a page that was there is still there, a redirect still redirects.
  • Every static route outside the sitemap, such as sign-in, account and admin entry pages, returns what it did before.
  • The released process is running and has stayed running for a few minutes, rather than restarting in a loop.
  • The app's error log since the restart has been read by a person, not just counted.
  • For APIs, a handful of real read requests return the same shape of answer as before.
  • The other apps on the server are still answering, so one release has not disturbed its neighbours.

  1. A tagged commit

    Only committed code ever runs in production. If the server holds changes that are not in the repository, we stop and reconcile them with you before going further, so nothing that works today is silently lost.

  2. Pushed over SSH

    The commit is pushed to the server directly. The server never holds the keys to your code host, so a compromised server cannot reach your other repositories.

  3. Exact dependencies

    Packages are installed from the lockfile, so production runs the versions that were tested, not whatever happened to be newest on the morning of the release.

  4. Built in place

    The app is built on the server with its own production settings, after clearing build caches that could otherwise bake old data into new pages.

  5. One app restarted

    Only the app being released restarts. Everything else on the server keeps running untouched, and visitors to the other apps never notice.

  6. Every URL checked

    The status of every sitemap URL and static route is compared with the version before, the process is confirmed running and the error log is read.

Anything differs? Roll back

The server resets to the previous commit, rebuilds and restarts, and we look at the difference with the live site already safe. Runtime upgrades keep the old runtime installed per app for the same reason, so going back is one step rather than a rescue.

Hardening

Seven layers we lock down, from the network edge to your data

Security on a server is layers, each assuming the one outside it might fail. This is the order we work in on every server we take on, our own included, and the order we report in, so you can see which layers are done and which are next. The outer layers are quick and stop most attacks; the inner ones take longer and limit the damage if something still gets through.

  1. Network

    A firewall that lets in web traffic and SSH only. Databases, caches and internal services are never reachable from the internet, even with a password.

  2. Sign-in

    SSH keys instead of passwords and no password login for the administrator account. At most 3 tries per connection, and 5 failures in a day bans the address for a week, rising to a year for repeat offenders.

  3. Secrets

    Environment files readable only by the account that runs the app, never committed, rotated without being printed to a screen or a log, and a names-only template in the repository.

  4. Runtime

    A supported long-term-support runtime, moved app by app with the previous one kept installed, so any app can switch back in one step if something behaves differently.

  5. Dependencies

    Audit fixes applied without forcing major upgrades. Majors are planned, changed in code and tested before they ship, never pushed through to make a warning go away.

  6. Application

    Framework security releases applied, admin tools kept off public routes, and rate limits on sign-in and one-time codes so the app cannot be used to flood anyone with messages.

  7. Data

    Least-privilege database users, backups away from the server, restores that have been tested, and personal data kept only as long as the product needs it.

When we take over a server, the first thing you get is a short report against these seven layers: what we found, what we changed that day because it could not wait, and what we propose next with the effort for each. Nothing is changed silently, and nothing that could interrupt your users is changed without a time agreed with you.

The application layer goes deeper than a server can: our pre-launch security checklist covers it item by item, including rate limiting and two-factor sign-in for staff. For an app someone else built, a code audit finds what the server cannot see.

Where to host

A rented server, a managed platform or a cloud account: what each is good for

There is no best host, only a best fit for what you run and who will look after it. We have no reseller deals, so the recommendation is the one we would make for our own product. For real numbers, see what apps cost to run; if you are already hosted and want to move, that is cloud migration, and the trade-off behind the last row is explained under vendor lock-in.

Usually rightRented server (VPS)Managed platformCloud accountServerless functions
Best forAPIs, web apps, sockets and scheduled jobs with steady trafficMarketing sites and front endsProducts that need specific managed services (queues, storage, media)Spiky, short tasks and webhooks
Running effortYou need someone to patch and watch itVery littleMost effort: many services and settingsLittle, until it needs debugging
Cost patternFlat monthly, predictablePer seat and per usage; rises with trafficPer usage across many line itemsPer call; cheap when idle, pricey when busy
Long connectionsFine (chat, live tracking)Often limitedFine with the right servicePoor fit
Scaling upA bigger server, then a second oneAutomatic, within the plan's limitsAutomatic, if set up for itAutomatic per call
Lock-inLow: standard LinuxMedium: platform featuresMedium to highHigh: provider-specific
What we set upEverything on this pageBuilds, domains, environment and previewsAccounts, roles, the services you need and their alertsFunctions, triggers, logs and limits

Many products end up with two: a managed platform for the marketing site and a rented server or cloud account for the API and database. We will say so if that is the cheaper, calmer answer, and we will say when your traffic has grown enough to change it.

The runbook you keep

Everything needed to run your product, written down in plain language

The test of a hosting handover is simple: could a new engineer deploy, roll back and renew everything without calling us? The runbook is how we pass that test. Here is the shape of one, with the real details replaced by placeholders. Yours names real people, real dates and real commands.

  • A runbook is not a wiki of everything we know. It is the shortest document that lets someone else do the five jobs that matter: deploy, roll back, rotate a secret, renew, and answer an alert.
  • We update it in the same change as the thing it describes. A runbook that is a release behind is worse than none, because people trust it.
  • It lives in your repository, next to the code, so it moves with the code if the code ever moves to another team.
  • Before we call it done, someone who did not write it follows it on a copy of the server. Every place they had to ask a question becomes a line in the runbook.

Runbook · your product

Where things live

  • code: your repository · branch main · tags for every release
  • server: the address and SSH key holders, listed by name
  • apps: one entry per process, with its port, runtime and start command
  • jobs: what runs when, and where its log is

Deploy

  • 1. push the tagged commit to the server
  • 2. install from the lockfile, build, restart this app only
  • 3. check every sitemap URL against the previous release

Roll back

  • reset to the previous tag, rebuild, restart; same checks
  • runtime: switch this app back to the previous version

Secrets

  • names: in the template file in the repository (no values)
  • values: on the server, readable by the app's account only

Renewals and owners

  • TLS: automatic · domain: renewal date, paid by you
  • alerts go to: named people, in order

Who does what

What you own, what we do and what the platform does, before launch and every month

Hosting goes wrong in the gaps between people: the renewal nobody paid, the alert that went to a former employee, the upgrade everyone assumed someone else had done. Writing down who owns each job is half of avoiding that. The three badges below are the version we agree with you before launch, and it goes into the runbook so it outlives everyone's memory of the conversation.

  • You

    Before launch
    Open the cloud or server account and the domain in your company's name; invite us with the access the job needs.
    Launch day
    Approve the go-live time and tell your team where to report problems.
    Every month
    Pay the hosting bill, keep the domain renewed and decide on the upgrades we propose.

  • Us

    Before launch
    Set up and harden the server, the database, TLS, backups, monitoring and the deploy, and write the runbook.
    Launch day
    Deploy, check every URL, watch errors and traffic, and stay on hand through the day.
    Every month
    Security updates, dependency checks, backup restores tested, alerts answered in working hours.

  • The platform

    Before launch
    Provides the machine, the network and the managed services you chose.
    Launch day
    Keeps the hardware and its network running.
    Every month
    Bills by its own rules; announces end-of-life dates we plan around.

Launch day, in order

  1. The day beforeA full backup taken and restored to a spare copy; DNS lowered to a short time-to-live so a change spreads fast; the rollback rehearsed once.
  2. Go-liveThe release deployed at the agreed time, the URL checks run, and DNS pointed at the new setup if the address is changing.
  3. First hourErrors, response times and sign-ups watched live; anything that differs from the rehearsal gets fixed or rolled back, not debated.
  4. First dayPayments, emails, push messages and scheduled jobs confirmed working with real traffic, one by one, against a written list.
  5. First weekAlerts tuned so they fire on real problems only, the runbook updated with anything launch taught us, and the DNS time-to-live raised again.

After launch, the monthly column is what our maintenance work covers. If you would rather run it yourself, the runbook is written so that you can. Either way, the three badges above go into that runbook word for word. See maintenance and support, our maintenance plans and pricing, and the agency handover checklist for what to hold if you ever move to another team. Shipping a phone app too? Our store launch service covers Google Play and the App Store.

Questions about deployment and hosting

Should our app run on a rented server, a managed platform or a cloud account?

It depends on what the app does. APIs with live connections, scheduled jobs and steady traffic usually sit well on a rented server, which is predictable and easy to move. Marketing sites suit a managed platform. A cloud account makes sense when you need its managed services, such as queues, media processing or storage at scale. We have no reseller arrangements, so we recommend what we would use ourselves, and we write down why.

Whose name should the servers, domain and cloud accounts be in?

Yours, always. We are invited as users with the access the job needs, and every account, renewal and bill is in your company's name. If we ever stop working together, nothing has to be transferred, only our access removed, which takes minutes rather than weeks of chasing.

Will you host and deploy code written by a different developer?

Yes, after we have read how it is built and how it currently runs. The first step, as in any app takeover, is usually reconciling what is on the server with what is in the repository, because they rarely match. If the code needs more than deployment work, we suggest an audit before we take responsibility for running it, so neither side is surprised later.

Do you offer 24/7 server monitoring?

No. Alerts reach us at any hour, but we answer them in Indian working hours, and we do not run a night-time on-call rota. We say this up front, as our maintenance and support terms do, because many products do not need round-the-clock cover, and those that do should buy it from a provider whose whole business is exactly that.

How do you undo a deploy that went wrong?

The previous release is always one step away. Each deploy is a tagged commit, and rolling back means resetting the server to the previous tag, rebuilding and restarting that one app, then running the same URL checks. When we upgrade a runtime, the old runtime stays installed so an app can switch back at once.

Can several of our apps share one server safely?

Yes, if each one is kept separate: its own process, its own runtime version, its own secrets readable only by it, and deploys made one app at a time. We run several apps per server ourselves this way. When one app's load starts to affect the others, we tell you, show you the numbers and move it.

How do we know what our hosting will cost each month?

We estimate it from what the app actually does: requests, storage, background jobs and third-party services such as maps or messaging, which often cost more than the server itself. Our running-costs page breaks these costs down for real apps. Once live, we set alerts on spend so a surprise shows up in days, not on the next invoice.

Do you set up automated deployment pipelines?

Yes. A release becomes one command or one push: dependencies installed from the lockfile, the build, a restart of the one app and the URL checks, with automatic rollback on any difference. Where your code host runs tests on every change, the deploy waits for them to pass before anything reaches the server.

status · your productAwaiting your details

Tell us what you run today, and where

Send a short list: the apps, the database, where they are hosted now and what worries you. An engineer reads it and replies with what we would change first, and what we would leave alone.

  • Your apps and APITell us what they are
  • Your databaseTell us where it lives
  • DeploysTell us how they happen today
Send us your setupAll services