How to Connect a Domain to CloudHosting
To use your domain with CloudHosting services, the domain must be pointed to our DNS infrastructure. Below are two options.
Option 1 — DNS Delegation to CloudHosting (recommended)
The fastest and most popular solution: you change your domain NS servers to CloudHosting and then manage all DNS records (A, AAAA, MX, TXT, CNAME) in one place.
This option is especially convenient if you use VPS / virtual servers or web hosting.
Set the following NS servers:
ns.cloudhosting.lv 91.220.43.5 (IPv6: 2a03:3440::91:220:43:5) (primary / master) ns2.cloudhosting.lv 185.8.60.254 (IPv6: 2a03:3440::185:8:60:254) (secondary / slave)
- DNS propagation may take up to 24–48 hours (depending on TTL).
- If the domain has email configured, make sure to keep MX and TXT records.
- If you need help with DNS transfer, contact us: Contacts.
Option 2 — Transfer a .lv domain to CloudHosting as the registrar
CloudHosting is an official .lv domain registrar. If you want to transfer your .lv domain to us as the registrar, send a request to NIC.LV.
Send an email to:
dns-reg@nic.lv Hello. Please transfer my domain name "your-domain.lv" to CloudHosting registrar. Thank you in advance.
After approval (usually within 24 hours), the domain will be transferred and delegated to CloudHosting DNS. Domain services and management are available in the Domain Registration section.
How Domain Transfer to CloudHosting.lv Servers Works
Transferring a domain name to CloudHosting.lv servers means that you update DNS settings so that visitors who enter your domain in a browser are routed to the new server infrastructure. In practice, this may involve either changing nameservers (NS) or updating specific DNS records (usually A/AAAA). In both cases, the main goal is to safely switch traffic to the new server while keeping the website operational, preserving email and integrations, and minimizing downtime as much as possible.
It is very important to distinguish “domain transfer” from “website migration”. The domain is an address that points to infrastructure via DNS. The website and services include files, databases, configurations, email, SSL certificates, cron jobs, and various integrations. Therefore, the correct order is: first prepare the new environment, test it, and only then change DNS. If you need a flexible environment with a dedicated IP, the ability to install your own software, and the option to test the project before a public switch, the usual choice is virtual servers.
For a safe transfer, it is recommended to create a short migration plan and checklist. This helps not only to “avoid forgetting something”, but also ensures a predictable rollback scenario. Even if everything is done correctly, there can be nuances: old server cache, DNS caching by internet providers, different server software versions, different PHP modules, permissions, or small configuration differences.
1) Prepare the new server and create backups. Before switching anything, create a full backup: website files, database, configuration, and (if needed) email data. A backup is your safety net. Then install the necessary software on the new server: web server (Nginx/Apache), database, required modules, and additional components (for example image processing, caching systems, or search). Import the database and upload the files.
2) Check configuration details before changing DNS. Typical “pain points” include file permissions, paths to uploaded files, sending email from the website, cron jobs, API keys, reCAPTCHA, payment gateways, webhook addresses, and redirect rules. If the previous environment had custom settings (for example extra Nginx location rules, .htaccess rewrites, or a customized set of PHP limits), make sure the new server matches them. If you use caching, confirm that caching does not hide dynamic content.
3) Test the website without switching DNS publicly. The safest approach is to redirect the domain to the new IP locally using the hosts file. This allows you to open the website by its domain name, but only on your own computer. Visitors will continue to see the old server while you test the new one.
Windows: C:WindowsSystem32driversetchosts Linux / macOS: /etc/hosts Example (replace with your IP and domain): 203.0.113.10 example.lv 203.0.113.10 www.example.lv
During testing, check more than just the homepage. Verify login, cart, checkout flow, filters, search, user profile, contact forms, image uploads, and every critical section that affects the business. If you run an e-commerce site, test the payment flow in “test mode” or at least make sure callback/webhook addresses are correct and nothing is blocked by a firewall. If you have integrations with a warehouse system or CRM, verify whether the new IP must be added to an allowlist.
4) Choose the DNS switching method: NS or A/AAAA. If you want CloudHosting.lv to fully manage DNS, you change NS records. This is convenient if you want DNS management in one place or if you need to reorganize your DNS zone. If you want to keep DNS at your registrar or a third party, it may be enough to update A/AAAA records to the new IP.
Example A record: Type: A Name: example.lv Value: 203.0.113.10 TTL: 300 Example AAAA record (if using IPv6): Type: AAAA Name: example.lv Value: 2001:db8::10 TTL: 300
5) Reduce TTL before switching. If TTL is high, changes will remain cached longer. A good practice is to reduce TTL to 300 about 12–24 hours before migration. This speeds up the switch and reduces the period when some visitors still reach the old version. After migration, TTL can be increased.
Recommended TTL before migration: 300 After migration (example): 3600 or 14400
6) Verify DNS responses before and after changes. Before switching, record which entries are active: A/AAAA, MX, TXT (SPF/DKIM/DMARC), CNAME, and any third-party verification records. After changes, verify that records return correctly and that you have not “forgotten” any important TXT or CNAME record affecting email or integrations.
Check A record: dig +short example.lv A Check NS records: dig +short example.lv NS Check MX (for email): dig +short example.lv MX
7) Plan for the “two-server period”. During DNS propagation, some users may reach the old server and others the new one. This is normal. However, for dynamic systems it can create data splitting — for example, an order is created on one server but not visible on the other. To prevent this, e-commerce sites and portals may temporarily limit changes (read-only mode), schedule migration during low traffic, or use short-term data synchronization. Not all websites need this, but it is important for critical systems.
What to Check to Avoid Surprises: Email, SSL, and Post-Migration Support
Email and MX records. If your domain is used for email, do not accidentally break MX records during migration. If email stays with your current provider, MX records can remain unchanged. If email is moving to the new server, treat it as a separate task: migrate mailboxes, transfer data, configure authentication, and only then change MX. Also remember to update SPF if the sending IP changes.
MX example: Type: MX Name: example.lv Priority: 10 Value: mail.example.lv SPF example (simplified): v=spf1 ip4:203.0.113.10 -all
SSL/HTTPS check. If your site uses HTTPS, the SSL certificate must be installed on the new server before public DNS switching. Otherwise, users may see a browser security warning. Check redirects (http → https), certificate validity, and whether there are “mixed content” issues. If you use a CDN, ensure the SSL mode (for example Full/Strict) matches the new environment.
Logs, errors, and performance. After switching, confirm the site works from different networks. It is recommended to test from home internet, mobile data, and office networks because DNS caching may differ. Review server logs: 404 errors can indicate missing static files, 500 errors can point to PHP/app issues, and slow load times can be caused by caching or database indexing differences. If you see many 404 errors after migration, you may need to review rewrite rules or media paths.
Post-switch checklist. Use this as a standard post-migration routine. If everything checks out, the migration is effectively complete.
1) Verify the domain points to the new IP (A/AAAA). 2) Check main pages and critical functions. 3) Verify HTTPS and certificate chain. 4) Test contact forms and website email sending. 5) Test payment/integration callback addresses (if any). 6) Review server logs (404/500/timeout). 7) After stability is confirmed — shut down the old server.
If your project is simpler and you do not want to handle server administration, it may be easier to use a managed solution where many technical tasks are handled at the service level, such as hosting. For larger systems with higher load that require predictable performance and full resource isolation, a more powerful infrastructure is often chosen, such as dedicated server rental.
In conclusion, transferring a domain name to CloudHosting.lv servers is a safe and controlled process when done step by step. Prepare the new environment, test it before public DNS changes, reduce TTL, consider email and SSL details, and perform thorough checks after switching. This approach allows you to switch the domain with minimal downtime and without harming the user experience.