Vloxt
Sign inView servers

Use case · Web hosting

Keep websites responsive as traffic and background work grow.

Start with Shared CPU; move to Dedicated CPU for sustained load.

Compare suitable servers

What kind of server is best for hosting websites?

Shared CPU is a strong fit for most websites, content platforms, and small online stores. Move to Dedicated CPU when traffic, background work, or database load makes consistent compute more important than the lowest starting cost.

What the server can support

  • Run the web application and its supporting services
  • Choose a region near the primary audience
  • Scale compute without changing the management workflow

Decide before deployment

  • Traffic pattern and peak concurrency
  • Database and cache placement
  • Backup and recovery requirements

Representative architecture

Keep each dependency visible.

This sequence is a planning model, not a prescribed topology. Change it when the application’s measured request and data paths require a different boundary.

  1. 01Visitors and edge cache
  2. 02Web application
  3. 03Database or managed data service
  4. 04Independent recovery copy
UsersRequest
Latency-sensitive
ApplicationCompute
Frequent round trips
DatabaseData
Independent copy
RecoveryRestore
Place the most conversational systems close together. Keep a recovery copy reachable through an independent access path.

Selection criteria

  • Measure peak concurrent requests and background jobs
  • Keep the application and frequently queried data close
  • Leave memory for the operating system, cache, and traffic bursts

Failure modes to test

  • CPU contention appears as slow dynamic requests
  • Memory exhaustion can terminate workers or the database
  • A remote database can dominate page response time

Catalogue connection unavailable

No configuration is being guessed.

Current active configurations could not be verified. Use the decision criteria on this page, then retry the catalogue when the connection recovers.

Retry matching catalogue

Recovery implication

Decide what must return before choosing how to protect it.

Protect uploaded data, database state, application configuration, and deployment credentials separately. Test a restore to an isolated target before relying on the process.

01 · DefineRequired data

Application, configuration, credentials, and database.

02 · ProtectIndependent copies

Server-level and application-aware recovery inputs.

03 · RestoreIsolated target

Recover without overwriting the source by default.

04 · VerifyWorking service

Check data, dependencies, access, and application behavior.

A completed backup job proves that a copy was written. A recovery drill proves that the service can return.

Pre-deployment checklist

  1. Load-test a representative dynamic page
  2. Monitor CPU, memory, disk, and application latency
  3. Document deployment rollback and database restore
  4. Move to predictable CPU only when measurement or failure cost justifies it

Choose from evidence, then observe

The suggested family is a starting point, not a guarantee of application performance. Test the software with representative traffic, monitor the constrained resources, and keep application-aware backups. Vloxt exposes eligible server controls and current catalogue choices; the application architecture remains yours.

Read the complete server-selection guide or explore platform features.