01
Separate website from product
Do not force the marketing site and custom application into the same operating model when their needs differ.
For startups
Hosting and infrastructure for startups
Use managed hosting for the public website and unmanaged VPS only when the product needs a custom runtime—and when someone on the team owns production operations.
Bitfoo opens for orders soon.
- Marketing site
- Shared hosting
- Custom product
- VPS candidate
- Primary goal
- Learn quickly
- Migration trigger
- Requirements
Managed platform
If operations are owned
Avoid speculative infrastructure
Not company age
What matters first
Preserve speed without accumulating invisible risk
The right early infrastructure is small enough to understand and disciplined enough to hand off.
02
Assign production ownership
A VPS decision requires a named person responsible for security, deployments, monitoring, and recovery.
03
Keep portability practical
Document code, data, DNS, secrets, and deployment so growth does not depend on one founder’s memory.
04
Use measurable triggers
Change capacity or architecture from observed resource use, reliability needs, or application requirements.
Recommended starting path
Choose the path per workload
The company stage does not decide the product. The runtime and operations model do.
Public website
Managed shared hosting
Use for WordPress, launch content, documentation, and conventional company pages.
- No server operator required
- Daily restore points and HTTPS workflow
- Application updates still belong to the team
Custom application
Unmanaged VPS
Use when the product needs persistent services and the team can operate the host.
- Custom runtime, workers, or containers
- Root access is a requirement
- Monitoring, security, and backup owners are assigned
Relevant services and guides
Build a staged product map
Give each workload the smallest operating model that satisfies its current requirements.
Company presence
Shared web hosting
Launch a managed company site without coupling it to the product’s server stack.
Explore shared hosting →Custom product
KVM VPS
Run a custom application when the team accepts the unmanaged server scope.
Explore VPS →Workload choice
Hosting by application
Review Next.js, Rails, Docker, Laravel, Node.js, Python, and Django guidance.
Browse workloads →Before committing
Prepare for the next teammate
The infrastructure should be understandable by someone who did not participate in every early decision.
- 01
Map accounts and ownership
Record domains, DNS, hosting, repositories, secrets, data stores, integrations, billing, and renewal owners.
- 02
Document each deployment
Make the marketing site and product release paths repeatable and separate.
- 03
Add meaningful monitoring
Observe the core customer path and dependencies before adding infrastructure for hypothetical scale.
- 04
Test portability
Restore or redeploy to a clean environment so the company is not dependent on one machine or founder.
Related guidance
Common questions
Should a startup begin on shared hosting?
Use shared hosting for a conventional company website. A custom product may need a different platform or VPS from the beginning, depending on its runtime and the team’s operational capabilities.
Can the marketing site and application use different products?
Yes. They often should. Separate them when their deployment, availability, security, or ownership requirements differ.
When should we move to VPS?
Move a workload when it requires root access, custom services, containers, persistent processes, or server-level control—and when someone can operate the server.
Does a larger VPS solve reliability?
Not by itself. A larger profile adds capacity. Application health, releases, monitoring, backups, recovery, and multi-host architecture remain separate decisions.