Skip to content

Managed website hosting and maintenance

Give the production website a responsible operating owner.

PlinthWeb manages the supported website’s deployment, platform configuration, availability checks, recovery path, routine technical care, and agreed small changes. The service names what is monitored, what response to expect, and where maintenance ends and new project work begins.

Discuss managed website care

Your context travels with you. Managed website care will already be selected in the form. Add the current site, desired outcome, and timing.

  1. 01

    Production deployment, domain connection, and SSL support

  2. 02

    Availability, form-path, and agreed integration checks

  3. 03

    Recovery plan and routine dependency maintenance

  4. 04

    Defined change allowance, response path, and service boundary

Service paths

Choose the scope that matches the problem.

01

Production operations

Keep deployment and essential configuration accountable.

Managed hosting covers the agreed production environment, deployments, domain connection support, SSL configuration, environment settings, and access needed to operate the site. The client retains ownership of the domain and business accounts, while roles and renewal responsibilities are documented to avoid a fragile handoff.

Availability checks and critical-path monitoring are configured to fit the website. A simple marketing site may need page, certificate, and form checks; a site with third-party scheduling or data flows may need additional boundaries because PlinthWeb cannot control another provider’s uptime or internal behavior.

  • Documented production environment and deployment path
  • Domain connection and SSL support
  • Availability and critical-path checks
  • Client ownership of domain and business accounts
02

Maintenance and recovery

Prepare for ordinary change and exceptional failure.

Routine care includes dependency and platform updates appropriate to the supported codebase, review of automated security notices, and regression checks proportionate to the change. Updates are not installed blindly: breaking releases, abandoned packages, and major platform migrations may require a separate implementation plan.

The recovery approach reflects the hosting platform and website architecture. Backups, source history, deployment rollback, content export, or another recovery mechanism may apply. The agreement states what is retained, how restoration is initiated, and which external data or services fall outside that recovery path.

  • Routine platform and dependency review
  • Proportionate regression checks after changes
  • Documented rollback or restoration path
  • Known limits for third-party systems and data
03

A clear support boundary

Distinguish maintenance from a new feature request.

The plan defines how to report an issue, the normal response window, the included allowance for small content edits, and the information needed to investigate. Priority reflects visitor impact and the supported website; it does not imply continuous staffing unless an agreement explicitly provides it.

Minor copy or image changes can fit the recurring allowance. New pages, redesigns, integrations, campaigns, content programs, and repairs to unsupported third-party code are estimated separately. This boundary protects routine care from an unlimited queue and lets larger work receive appropriate planning and testing.

  • Named issue-reporting and response process
  • Defined small-change allowance
  • Priority based on website impact
  • Separate estimates for features and major changes

How managed care begins

Four steps from technical intake to steady operations.

A short onboarding phase establishes ownership, baselines, recovery, and support expectations before recurring care starts.

  1. 01

    Assess and document

    Review the codebase, host, domain, dependencies, integrations, access, current issues, and ownership boundaries.

  2. 02

    Stabilize and migrate

    Resolve agreed blockers, configure the supported environment, and move deployment or hosting when the scope requires it.

  3. 03

    Monitor and maintain

    Run availability and critical-path checks, review dependencies and alerts, and complete routine technical care.

  4. 04

    Report and plan

    Summarize completed work and issues, use the change allowance, and estimate larger improvements separately.

Managed hosting and maintenance questions

Will we still own the domain and website accounts?

Yes. Business-critical accounts should remain under client ownership with appropriate management access granted to PlinthWeb. Source-code, deployment, and handoff terms follow the signed project agreement, and third-party software remains subject to its own license.

Does monitoring mean someone watches the site every minute?

No. Automated checks can run frequently and raise an alert, but the agreement defines review and response windows. Continuous staffed monitoring or emergency coverage is a different operational commitment and is not implied by a standard care plan.

Are content updates included?

A defined allowance for small text or image changes can be included. Unused time, turnaround, supported formats, and exclusions are stated in the plan. New pages, features, and substantial rewrites are scoped separately.

Can you take over a website you did not build?

Possibly. A technical intake determines whether the code, platform, licensing, access, and current condition are supportable. Stabilization, migration, or a rebuild may be recommended before managed care if the existing setup is unsafe or impractical to maintain.

Related guides

Go deeper before choosing the next step.

Make care explicit

Show us the website that needs an operating owner.

Share the site, host, platform, repository status, domain ownership, integrations, update needs, and known problems. We will identify the intake work and a realistic care boundary.