Managed hosting vs self hosting needs a labor budget

Twenty small tools rarely need much compute. They do create twenty chances for a certificate to expire, a backup to fail silently, a dependency upgrade to break login, or an alert to reach nobody. That is why a hosting comparison based only on the monthly server bill gives the wrong answer.

For a portfolio this size, managed hosting usually costs less once the owner prices staff time and interruption. Self hosting can still win when the tools share a disciplined platform, the team already operates it, and control or data-location requirements justify the work. The decision belongs in a total-cost model, not in a screenshot of two pricing pages.

Compare one operating service, not one virtual machine

The fair unit of comparison is an operating service that users can reach and that someone can recover, not a virtual machine with enough memory to start the code. A cheap server quote excludes much of what keeps an application useful after deployment.

For each option, define the same service boundary. Include the application runtime, database, persistent files, DNS, TLS termination, secrets, logs, metrics, alerts, backup storage, restore procedure, deployment path, rollback path, security updates, and an owner who responds when something fails. If a managed plan includes some of these, record them as included. If it delegates them to you, price them on the self-hosted side too.

The field often blurs infrastructure management with application ownership. Managed hosting may patch the host and replace failed hardware, but it cannot decide whether yesterday's schema migration lost a column or whether an AI-generated authorization check is wrong. Self hosting expands your responsibility downward into the operating system, network rules, database setup, and monitoring stack. It does not remove the application work above that line.

AWS explains the same boundary in its shared responsibility model: with infrastructure services, the customer manages the guest operating system, security patches, application software, and firewall configuration. Renting a virtual machine from a large provider therefore does not make the application managed. It only means the provider operates the physical layer beneath your machine.

Start the comparison with an ownership table. For every row, write one accountable person or vendor and the response promised. A row marked "automatic" is incomplete until you know who notices when the automation stops.

This table prevents the most common accounting trick: comparing a complete managed service with an empty server. It also exposes managed plans that sound complete but leave database recovery or after-hours response to the customer.

Use a cost model that charges for interruptions

A useful model separates recurring cash, planned labor, and unplanned labor. Mixing them into one optimistic monthly estimate hides the part that varies most.

Use this calculation for each option:

Annual cost = 12 x recurring monthly cash
            + planned engineering hours x loaded hourly rate
            + expected incident hours x loaded hourly rate
            + expected outage impact
            + one-time migration or platform work amortized over its useful life

Recurring cash includes compute, databases, storage, backup storage, network egress, monitoring, log retention, DNS, certificate services if paid, and support plans. Planned labor includes releases, patching, backup checks, restore drills, access reviews, dependency upgrades, capacity changes, and documentation. Incident hours include diagnosis, repair, recovery, communication, and the follow-up work that prevents a repeat.

Use a loaded hourly rate, not take-home pay. The rate should reflect salary or contractor cost plus the overhead the organization actually carries. If a founder does the work at night, the rate is not zero. Use the value of the product, sales, or customer work displaced by that maintenance window. Free labor is where self-hosting spreadsheets go to lie.

Do not pretend that uncertain incidents can be forecast precisely. Make three cases instead: quiet, expected, and bad. The quiet case may have one minor event and routine patching. The expected case includes a failed deployment, a restore request, noisy alerts, and several urgent upgrades. The bad case includes an extended recovery or a compromised credential. The ranges matter more than a single polished total.

A compact worksheet for twenty tools can use portfolio-level assumptions:

These are example inputs, not universal benchmarks. Replace them with your release frequency, on-call history, recovery requirement, and internal labor rate. If no history exists, keep the range wide and revisit it after three months.

Portfolio math also needs a fixed-cost line. Building a reusable deployment platform might take substantial effort once, then support many tools. Divide that cost over the number of applications and the period you expect to keep the platform. Do not assign the entire platform cost to the first tool, and do not make it disappear from all twenty.

Twenty tools multiply surfaces faster than compute

Small applications consolidate well for CPU and memory, but their operational surfaces do not shrink at the same rate. One server may run twenty containers, yet each tool can still have a domain, secret set, user group, database schema, release cadence, dependency tree, and recovery expectation.

This is why the twentieth tool changes the economics. A manual task that takes six minutes per application consumes two hours across the portfolio before troubleshooting. A quarterly check becomes eight staff-hours a year. Add coordination, failed runs, and documentation, and the task stops being trivial even though every individual tool looks trivial.

Consolidation cuts cash but increases the blast radius. If all tools share one host, a kernel update, full disk, broken reverse-proxy configuration, or lost credential can stop all twenty. Splitting them across hosts reduces that shared failure but raises bills and patching work. Managed platforms usually spread that infrastructure work across many customers; a self-hosted team has to design and pay for its own balance.

Treat the portfolio as a set of service classes rather than twenty unique pets. A useful grouping might be disposable prototypes, internal tools with reproducible data, business tools with authoritative data, and public tools with external users. Each class gets a standard runtime, backup policy, monitoring policy, recovery target, and retirement rule. Tools graduate only when their risk changes.

The recommendation to give every tool its own virtual machine remains popular because isolation is easy to explain. For twenty small tools, it is usually the wrong default. It duplicates patching, monitoring agents, certificates, configuration, and idle capacity. Use stronger isolation for a reason, such as conflicting dependencies, sensitive workloads, or a materially different recovery target. Containers or a shared application platform usually fit the rest.

The opposite extreme, putting every database and application into one undocumented compose file, also creates a false saving. You need resource limits, persistent-volume names, health checks, predictable routing, and a record of which tool owns which data. Otherwise one runaway export fills the disk and turns a minor application bug into a portfolio outage.

Count retired tools too. AI-assisted development makes creation cheap, so abandoned experiments accumulate. A monthly inventory should identify tools with no owner, no users, or no recent deployment. Deleting an unused service reduces attack surface and operational work more reliably than tuning its container to save a few cents.

Backups cost little until you require a restore

A backup is a recoverable copy with a tested path back into service. A scheduled job that uploads files somewhere is only evidence that a command ran.

For each service class, write a recovery point objective and a recovery time objective in ordinary language. "We can lose up to one business day of edits and restore within four working hours" is enough to design against. A public form that forwards submissions may tolerate a different loss window than an internal CRM that holds the authoritative customer record.

Database backup cost has four parts: creating copies, storing them, retaining enough history, and proving they restore. The fourth part usually dominates labor. A restore drill needs a clean target, credentials, time to download data, database startup, application checks, and a decision about whether the recovered state is acceptable.

PostgreSQL documentation draws a useful distinction. A logical pg_dump can restore database objects and data, while continuous archiving combines base backups with write-ahead log files for point-in-time recovery. The manual also warns that the WAL sequence must remain complete back to the base backup. Calling both approaches "daily backup" hides different recovery abilities.

For small databases, a plain encrypted dump may be the right trade when a day of data loss is acceptable. Keep multiple generations in storage that is separate from the application host, record the encryption-key owner, and test a restore. If the business needs recovery to a point just before an accidental deletion, use a managed database that offers that capability or operate WAL archiving properly. A folder of nightly dumps cannot meet that promise.

A minimal restore record should capture facts rather than confidence:

service: inventory-tool
backup_object: inventory-tool/2026-07-12T020000Z.dump
restore_started: 09:14 UTC
restore_finished: 09:31 UTC
application_check: login, search, create and delete test record passed
recovery_point: 02:00 UTC
operator: initials

This output shape lets an owner prove which copy was restored and what the check covered. Store the record beside operational documentation, not only inside the monitoring system that might be unavailable during a failure.

Managed backups still need scrutiny. Check retention, geographic location, encryption, export access, deletion behavior, and whether restoration creates a new database or overwrites the current one. Confirm whether snapshots include uploaded files and secrets. Managed hosting saves labor when the platform owns these mechanics, but the customer must still choose the policy and verify a real restore.

SSL and monitoring are automation with owners

TLS certificates can have no purchase price and still create work. DNS records must point correctly, challenges must succeed, the reverse proxy must load renewed material, and alerts must reach someone before expiration.

Let's Encrypt says its certificates historically used short lifetimes to encourage automation. That policy makes sense, but "we use Let's Encrypt" is not an operating procedure. The procedure names the ACME client, renewal schedule, challenge type, DNS permissions, reload behavior, expiry alert, and person who handles failure.

With twenty custom domains, manual certificate handling is indefensible. Use automatic issuance and renewal, then monitor the result from outside the host. An external check catches a certificate that exists on disk but was never loaded by the proxy. It also catches DNS mistakes and a dead server, which a local renewal log cannot.

Monitoring needs similar restraint. Prometheus guidance recommends alerting on symptoms tied to user pain and avoiding pages that require no action. That advice matters for small-tool portfolios because a copied stack of CPU, memory, container, database, and proxy alerts can produce hundreds of notifications without telling the operator whether anyone is blocked.

For each tool, start with an external availability check, error-rate signal, latency signal, storage-capacity warning, backup-freshness check, and certificate-expiry check. Page only when a human needs to act soon. Send slower capacity or maintenance issues to a daytime queue. Every page needs an owner, a short diagnostic path, and a silence or maintenance mechanism.

Monitor the monitor. If all internal checks run on the same host as the applications, a host failure also removes the alarm. At least one check and its notification path should live outside the failure domain. Managed platforms often provide basic health and deployment status, but verify whether they test your actual application route and whether their notifications match your response needs.

Log retention belongs in the cost model as well. Twenty chat-generated tools can emit verbose request logs, framework warnings, and repeated stack traces. Set retention by use: short searchable logs for diagnosis, longer audit records only where the application needs them, and filters for secrets or personal data. Unlimited retention is expensive and risky; no retention makes the first incident longer.

Upgrades turn generated code into owned code

Deploying AI-generated software transfers maintenance responsibility to the operator. The model that produced the code does not patch its packages, test a runtime upgrade, or explain why a transitive dependency disappeared six months later.

Price upgrades at every layer you own: operating system, container base image, language runtime, framework, packages, database, reverse proxy, monitoring stack, and deployment tooling. A managed platform may remove the host and runtime layers from your queue, but application dependencies remain yours. Source-code export also means you can leave a platform, not that exported code operates itself.

The cheapest workable pattern is a standard build contract. Every tool should build from a locked dependency file, run a small automated test set, expose a health endpoint, apply database migrations explicitly, and retain a known previous release. Without that contract, each upgrade becomes an archaeological dig through generated code.

Use a recurring maintenance window. Group low-risk dependency updates, rebuild images, deploy one representative tool, then roll through the service class. Keep security fixes on a faster path. Record unsupported runtimes and packages in one portfolio view so an owner can see debt before an urgent upgrade lands.

Snapshots and rollback reduce deployment recovery time, but they do not replace database planning. Rolling application code back after a destructive migration can leave old code facing a new schema. Prefer backward-compatible changes: add a field, deploy code that handles old and new states, migrate data, then remove the old field in a later release. That sequence costs more attention up front and much less at 2 a.m.

A planning mode is useful before changing a generated application because it gives the owner a chance to inspect scope, data changes, and affected components. Koder.ai combines planning, deployment and hosting, custom domains, snapshots, and rollback, so a team can price those operations as one managed path while keeping source export as an exit option. The comparison still needs an application-maintenance line because no hosting choice removes ownership of the behavior you ship.

Do not count an upgrade as complete when the deployment command exits successfully. Check login, one read path, one write path, background work, and the specific feature affected by the update. Five purposeful checks beat an unowned test suite with a green badge nobody trusts.

Incident response is the bill that arrives at the worst time

Incident cost includes the interruption, not only the minutes spent typing commands. One broken internal tool may block a finance process, delay twenty staff members, or force error-prone work into spreadsheets. A public tool can create support work even when its direct revenue is zero.

Walk through a plausible self-hosted failure. A tool starts writing large export files to its application volume. Disk usage crosses the warning threshold, but the alert goes to an old mailbox. The disk fills overnight. PostgreSQL and several sibling containers stop writing. The morning operator frees space, restarts services, discovers an incomplete database file, and reaches for backups. The nightly dump is present, but nobody has restored it for nine months and its encryption key belonged to a departed contractor.

The server invoice barely changes during this event. The expensive parts are diagnosis across several layers, uncertainty about the backup, affected staff time, recovery work, status messages, and follow-up changes. Managed hosting may prevent the disk and database portions or give faster recovery controls, depending on scope. It will not repair a bad application export or contact users for you.

Price response roles before choosing the cheaper option. Who receives an alert outside working hours? How quickly must that person respond? Who can change DNS, restore data, rotate secrets, and communicate status? What happens during holidays? If the answer is "the developer," confirm that the developer has access, documentation, and paid time reserved for the job.

A twenty-tool portfolio does not always justify formal round-the-clock on-call coverage. It does require an explicit service window. Some internal tools can wait until the next business day. State that promise to users and configure alerts accordingly. Reserving urgent response for the few tools that need it cuts cost and alert fatigue.

After an incident, charge the repair that removes the failure mode to the hosting option. If self hosting repeatedly needs manual disk cleanup, certificate repair, or monitor maintenance, those hours are part of its price. If a managed provider causes repeated deploy failures or slow support exchanges, count that time on its side. Cost models improve when they remember pain instead of resetting to the brochure price each month.

Self hosting wins only with a shared platform and a reason

Self hosting can cost less when the organization already has a maintained platform, spare operational capacity, and requirements that managed products cannot meet economically. It rarely wins because one virtual machine is cheap.

A credible self-hosted plan for twenty tools has standard templates, automated deployments, central secrets, external monitoring, automatic TLS, separated backup storage, tested restores, patch ownership, resource limits, and written retirement procedures. Most tools should fit that paved path without bespoke infrastructure. If every new tool needs a new server diagram, the platform is not paying back its fixed cost.

Control may justify the expense. Data residency, network isolation, unusual runtime needs, predictable high utilization, or an existing compliance boundary can favor self hosting. Put a monetary value or mandatory requirement beside that control. "We prefer control" cannot be compared with a managed invoice and often means the team has not named the constraint.

Managed hosting is the stronger default for a small team, uneven usage, frequent creation and deletion, or no one assigned to operations. It converts several uncertain labor lines into a visible subscription and reduces the number of layers the team must own. Verify limits, backup behavior, log access, supported regions, custom-domain handling, rollback, export, and support response before treating the subscription as complete.

Run the decision through a break-even calculation:

self_hosting_saving = managed_annual_cash - self_hosted_annual_cash
hours_available = self_hosting_saving / loaded_hourly_rate

If self hosting saves $6,000 a year and loaded labor costs $100 an hour, it buys 60 hours of annual operations work. That is five hours a month for patching, monitoring, backups, restore drills, deployment failures, and incidents across twenty tools. The arithmetic does not declare a winner, but it makes an implausible plan visible.

Then test sensitivity. Double the incident hours, add the cost of a second operator, or assume three tools need point-in-time recovery. If a tiny assumption flips the answer, choose based on risk tolerance and control requirements rather than claiming a durable cost advantage.

Make the decision with a 90-day operating trial

The most defensible choice uses measured work from your own portfolio. Run a 90-day trial with a representative group, record every cash charge and staff task, then project the result to twenty tools.

Choose at least one disposable prototype, one internal tool with a database, and one externally reachable application. Give them the service policies they would have in production. During the trial, deploy changes, renew certificates, restore a backup into a clean environment, roll back one release, rotate a secret, trigger an alert, and retire a tool. A trial that only measures quiet uptime misses the work under comparison.

Record operations in a small ledger:

Separate active and waiting time. An operator may do other work while a backup downloads, but a fifteen-minute interruption in the middle of product work still has a switching cost. Use one consistent rule for both hosting options.

At day 90, annualize recurring work, keep one-time setup separate, and compare the three incident cases. Review any responsibility that was never exercised. If nobody tested DNS recovery, region placement, or support escalation, mark it unknown instead of assuming it works.

For most teams building twenty small AI-generated tools, the trial will show that compute is the smallest interesting number. Managed hosting wins when its extra cash cost buys more staff time than the team spends managing its remaining responsibilities. Self hosting wins when a reused platform keeps that work below the break-even allowance and the added control has a named purpose.

Do not approve the cheaper-looking plan until someone signs their name beside restores, patches, alerts, and incidents. Servers are commodities. Reliable ownership is the scarce line item.