Хостинг
Hosting is a service for owners of websites, online stores, applications, and internal systems that need dependable infrastructure without undocumented changes or dependence on one contractor. DitWork lets customers compare specialists by relevant experience, diagnostic quality, security planning, documentation, and post-change support. A useful estimate requires the current architecture and a measurable target, not a vague request to configure everything.
In the Hosting category, customers can order selection of shared hosting, VPS, dedicated, or cloud, comparison of resources, limits, and support, migration of files, databases, and user uploads, configuration of PHP, databases, cron, and queues, HTTPS, CDN, and caching setup, migration of email settings and DNS and backups and monitoring. Separate the mandatory result, optional improvements, and ongoing support. A one-time migration, continuous monitoring, and round-the-clock incident response are different services with different responsibility, so they should be scoped and priced separately.
Tasks you can order
- selection of shared hosting, VPS, dedicated, or cloud
- comparison of resources, limits, and support
- migration of files, databases, and user uploads
- configuration of PHP, databases, cron, and queues
- HTTPS, CDN, and caching setup
- migration of email settings and DNS
- backups and monitoring
Deliverables by stage
| Stage | Deliverable | Verification |
|---|---|---|
| Audit | Current-state and risk map | Services, access, and dependencies are documented |
| Preparation | Backup and change plan | A verifiable rollback path exists |
| Implementation | Configured infrastructure | Critical scenarios work |
| Handover | Documentation and owner access | The result does not depend on the contractor account |
What to include in the brief
The brief should include website type and CMS or framework, current file and database size, average and peak traffic, required PHP, database, and extension versions, cron jobs, queues, WebSocket, and background processes, region, latency, and data-location requirements and acceptable downtime and cutover deadline. Add anonymized error examples, a service map, and an available owner contact for the cutover window. Never publish passwords, private keys, tokens, recovery codes, customer data, or closed configuration in the public task. Access should be provided only after choosing a specialist and limited to the work being performed.
- website type and CMS or framework
- current file and database size
- average and peak traffic
- required PHP, database, and extension versions
- cron jobs, queues, WebSocket, and background processes
- region, latency, and data-location requirements
- acceptable downtime and cutover deadline
What to check before work starts
Before changes begin, review actual CPU, memory, and disk use, database size and slowest queries, outbound traffic and user-upload volume, limits of the current plan, dependence on system email and external APIs, availability of backups and application requirements for processes, ports, and filesystem access. Without an inventory, a specialist can fix one visible symptom while breaking a dependent service. The audit should distinguish infrastructure failure from an application bug, plan limitation, external API issue, or incorrect DNS record. When the cause is unknown, order diagnosis and a written report before paying for an undefined collection of actions.
- actual CPU, memory, and disk use
- database size and slowest queries
- outbound traffic and user-upload volume
- limits of the current plan
- dependence on system email and external APIs
- availability of backups
- application requirements for processes, ports, and filesystem access
How the work is performed
A safe workflow includes select a plan from measured requirements, create a test environment, copy files, databases, and configuration, run the site on the new hosting, verify forms, payments, email, cron, and APIs, perform a controlled DNS cutover and observe errors and resource use after launch. Every critical change needs a backup and a clear reversal method. Verification must cover more than the visual home page. Test real user journeys, background processes, notifications, logs, resource limits, and behavior after restart.
- select a plan from measured requirements
- create a test environment
- copy files, databases, and configuration
- run the site on the new hosting
- verify forms, payments, email, cron, and APIs
- perform a controlled DNS cutover
- observe errors and resource use after launch
Technical and security requirements
Technical requirements should include supported software versions without obsolete dependencies, separate production and test configuration, HTTPS with automatic certificate renewal, restricted file and user permissions, backups outside the primary account or server, availability and resource monitoring and a clear scaling path for higher load. Shared passwords, permanent root sessions, secrets in chat, and disabling protection for a quick launch create long-term risk. Permissions should match each role, while the project owner must retain an independent recovery path that does not require the former contractor.
- supported software versions without obsolete dependencies
- separate production and test configuration
- HTTPS with automatic certificate renewal
- restricted file and user permissions
- backups outside the primary account or server
- availability and resource monitoring
- a clear scaling path for higher load
What the specialist should deliver
After completion, request hosting account owned by the customer, plan, resource, and limit inventory, a copy of website and database configuration, deployment and recovery instructions, DNS record list and cutover date, backup and monitoring documentation and a resource-upgrade or migration plan for growth. Documentation is not ceremonial. It makes the result repeatable so another specialist can find configuration, verify operation, identify dangerous actions, restore the system, and understand who owns each account. Configuration exports and instructions should be stored with customer-controlled recovery materials.
- hosting account owned by the customer
- plan, resource, and limit inventory
- a copy of website and database configuration
- deployment and recovery instructions
- DNS record list and cutover date
- backup and monitoring documentation
- a resource-upgrade or migration plan for growth
What affects the price
The price of Hosting depends on infrastructure type and management level, file and database volume, need for email migration, minimum-downtime requirements, CDN, object storage, and multiple regions, application and background-process complexity and ongoing administration and support. Compare proposals against the same scope. A low estimate may omit diagnosis, backup, testing, related-service fixes, observation after cutover, and documentation.
- infrastructure type and management level
- file and database volume
- need for email migration
- minimum-downtime requirements
- CDN, object storage, and multiple regions
- application and background-process complexity
- ongoing administration and support
How to choose a specialist
When choosing a Hosting specialist, ask for a description of a similar project without exposing another customer data. A reliable contractor asks about dependencies, access, backups, maintenance windows, monitoring, and acceptance criteria. They do not promise perfect security or zero downtime without reviewing the architecture, and they explain the remaining risks in advance.
How to accept the result
Before acceptance, verify the website and APIs work on primary addresses, HTTP and HTTPS do not create redirect loops, forms and email are actually delivered, cron jobs, queues, and schedulers run, user files are available and complete, backups run and recovery is documented and resources are not immediately exhausted after launch. Judge the result through agreed scenarios and logs rather than a control-panel screenshot. Save check commands, change date, before-and-after values, contacts, and a repeatable response plan for a future incident.
- the website and APIs work on primary addresses
- HTTP and HTTPS do not create redirect loops
- forms and email are actually delivered
- cron jobs, queues, and schedulers run
- user files are available and complete
- backups run and recovery is documented
- resources are not immediately exhausted after launch
Hosting should be selected from application requirements and measured load, not only price, disk space, or an advertised unlimited plan. Shared hosting may suit a simple website, while queues, custom processes, WebSocket, or unusual extensions may require a VPS, containers, or a managed platform. A migration must test more than the home page because failures often appear in cron jobs, system email, background workers, upload permissions, request limits, time zones, and filesystem paths.
Access, responsibility, and service boundaries
In a Hosting task, the customer is responsible for lawful data use, provider payments, ownership of domains and accounts, business-risk approval, and protection of shared secrets. The specialist is responsible for the agreed configuration scope, minimum permissions, change records, and warnings about discovered limitations. Application development, legal review, round-the-clock on-call service, and license purchases are included only when explicitly agreed.
How to post a task on DitWork
To order Hosting on DitWork, post the current architecture, goal, service inventory, symptoms, deadline, and allowed change window. State whether the task is a one-time setup, migration, audit, or ongoing maintenance. Compare proposals by plan quality, access security, verification scope, documentation, and the ability to recover after a mistake.
