Mga Tampok
Ituro ang app, shop, docs o staging saanman mo gusto at kumuha ng tunay at lubos na nakahiwalay na site sa likod nito: ang sarili nitong stack, database, cache, backup, at resource cage. May ganap na kontrol sa DNS record, awtomatikong SSL kabilang ang mga wildcard, at one-click staging subdomain. Availability: ang per-site database throttling ay kasalukuyang ginagawa at hindi pa available. Ang lahat ng iba pang inilarawan dito ay live na ngayon.
Sa karamihan ng mga host, ang subdomain ay isang direktoryo na may rewrite rule sa harap nito. Dito, ito ay isang first-class site record na may sarili nitong blueprint version, sariling pagkakalagay sa fleet at sariling isolation boundary. Anuman ang maaari mong gawin sa isang pangunahing domain, maaari mo ring gawin sa isang subdomain.
Ang bawat subdomain site ay ginawa mula sa isang bersyon na blueprint at nagpapatakbo ng sarili nitong stack type at runtime: managed WordPress, WooCommerce, PHP, static HTML o Node. Ang iyong docs subdomain ay maaaring maging static HTML habang ang root ay nagpapatakbo ng WordPress, nang walang kompromiso sa pagitan nila.
Isang MariaDB database bawat site, LiteSpeed LSCache full-page caching, at bawat site na Redis o Memcached object cache. Walang ibinabahagi sa parent site, kaya ang isang mabigat na subdomain ay hindi makakapag-evict ng cache ng parent o makakasikip sa mga query nito.
Nililimitahan ng CloudLinux LVE ang CPU, RAM, IO, IOPS at entry processes sa bawat site, binibigyan ng CageFS ang bawat site ng sarili nitong view sa filesystem, at pinamamahalaan ng MySQL Governor ang load ng database sa bawat site. Ang isang lumalabag na subdomain ay nakakulong sa sarili nitong hawla.
Ang mga araw-araw na backup ay itinatago sa loob ng 30 araw na may kasamang one-click restore, bawat site. Maaari mong ibalik ang isang subdomain kahapon nang hindi ginagalaw ang parent site o alinman sa mga sibling nito.
Ang mga subdomain ay isang problema sa DNS bago pa man ito maging problema sa hosting, kaya naman ang DNS layer ay wastong inilalantad sa halip na itago sa likod ng isang pormularyo na may dalawang field.
Ang bawat maire-rehistrong domain na iyong hinohost ay may DNS zone na pinamamahalaan sa pamamagitan ng aming DNS driver seam. Mayroon kang record CRUD sa mga uri ng record na iyong inaasahan, kaya ang pagdaragdag ng app, shop, docs, mail o wildcard host ay isang record edit, hindi isang support ticket. Ang state ng zone ay idempotently na nire-reconcile laban sa provider, ibig sabihin ang kalahating nailapat na pagbabago o ang inulit na edit ay tutungo sa state na iyong hiniling sa halip na iwanan ang iyong zone sa isang hindi malinaw na gitna.
Sadyang pinaghiwalay ang registrar at DNS: maaari kang magrehistro ng domain sa amin at panatilihin ang DNS sa iba, o panatilihin ang domain sa iyong umiiral na registrar at ituro lamang sa amin ang isang subdomain. Bineberypika namin ang delegasyon at aktibasyon ng nameserver bago namin ipalabas na live ang isang domain, kaya malalaman mo na mali ang isang record mula sa platform kaysa mula sa isang customer.
Ang isang subdomain na mabagal o nagpapakita ng babala sa sertipiko ay mas masahol pa kaysa sa walang subdomain, kaya ang landas ng paghahatid ay pareho sa natatanggap ng pangunahing domain.
Ang mga sertipiko ng Let's Encrypt ay awtomatikong ibinibigay at nire-renew. Gumamit ng wildcard certificate para masakop ang bawat subdomain nang sabay-sabay, per-host certificates kung gusto mong paghiwalayin ang mga ito, o i-upload ang iyong sariling custom certificate.
Pinaglilingkuran ng LiteSpeed ang bawat site na may HTTP/3 na nakapagana, kaya nakukuha ng isang subdomain ang parehong pagganap sa antas ng koneksyon tulad ng root domain sa halip na maging isang pangalawang klaseng vhost.
Ang LSCache full-page caching pati na rin ang per-site Redis object cache, na may coordinated purge mula sa dashboard o mula sa loob ng WordPress. Ang pag-purge sa magulang ay hindi nagbubura sa cache ng iyong subdomain.
I-deploy sa pamamagitan ng aming CDN at Cloudflare account pool o ikonekta ang sarili mong mga account at piliin kung aling account ide-deploy ang isang partikular na site. Ang paghahatid ay desisyong ginagawa mo, hindi namin ginagawa para sa iyo.
Ang pinakakaraniwang dahilan kung bakit gusto ng subdomain ay para magkaroon ng ligtas na lugar para sumubok at sumira. Naka-built-in at bukas ang landas na iyon sa mga plan na Mainstream.
Ang pag-clone sa staging ay lumilikha ng nakahiwalay na kopya ng live na site sa isang staging subdomain, kasama ang mga file at database nito nang buo, sa parehong stack at bersyon ng blueprint tulad ng production. Nagtatrabaho ka sa kopya gamit ang buong toolset: nakakulong na SSH at SFTP, wp-cli, ang VS Code editor na nakabase sa browser, phpMyAdmin o Adminer, cron sa bawat site, at mga variable ng kapaligiran.
Kapag napatunayan na ang pagbabago, ang push to live ay nagsasagawa ng database-aware na sync pabalik sa production. Pinipili mo ang mga file, database, o pareho, at ang search-replace ay pinangangasiwaan para sa iyo upang ang mga URL sa iyong nilalaman ay sumunod sa site sa halip na tumuro pabalik sa staging host. Dahil ang provisioning, cloning, at deployment ay tumatakbo bilang mga matatag na Temporal workflow na may per-step na pagsubok muli at kabayaran, ang pagkabigo sa kalagitnaan ay nag-aalis ng hindi tapos na gawain sa halip na iwan kang may kalahating naka-clone na site.
Mas gusto naming sabihin ito sa iyo nang maaga kaysa magbenta sa iyo ng isang bagay na sisira sa sinusubukan mong gawin.
Ang mga subdomain ang tamang sagot para sa pag-aayos ng isang brand: isang app, isang shop, isang docs site, isang customer portal, o isang staging environment para sa bawat kliyente. Ang mga ito ay maling sagot para sa isang pribadong blog network. Ang bawat subdomain ay nagbabahagi ng iisang registrable domain, kaya alam ng sinumang mag-resolba sa isa sa mga ito kung sino talaga ang nagmamay-ari ng iba pa. Sa ilalim ng isang wildcard certificate, nagbabahagi rin sila ng isang sertipiko, at ang pagpapalabas ng sertipiko ay nai-publish sa mga pampublikong Certificate Transparency log, kaya ang mga host sa ilalim ng isang nakabahaging domain ay madaling mabilang ng sinumang gustong tumingin. Katangian iyon ng pampublikong web PKI at DNS, hindi ng aming platform, at walang configuration ng hosting ang makakapagbago nito.
Kaya ang mga subdomain ay nasa aming mga linyang Mainstream at Agency, at hindi sa Footprint-Free. Kung ang kinakailangan mo ay hindi dapat maiugnay ang mga site sa isa't isa, kailangan mo ng mga hiwalay na nairerehistrong domain sa linyang produkto ng footprint-free, kung saan umiiral ang mga pool ng CDN at DNS account, pamamahala ng footprint, at paghahatid ng static-HTML tiyak upang sirain ang pattern na iyon. Pareho silang gumagana sa parehong engine at sa parehong dashboard, kaya ang tamang pagpili ay walang gastos sa iyong kaginhawaan.
Gumagamit ang mga ahensya at reseller ng mga subdomain nang maramihan: isang staging host sa bawat kliyente, isang preview host sa bawat proyekto, isang portal sa bawat account. Ang plataporma ay binuo para sa ganoong uri ng gawain.
Ang mga organisasyon ay nakaayos bilang isang puno, mula sa reseller hanggang sa kliyente hanggang sa mga site, at ang bawat rekord ay may saklaw at ipinapatupad sa database na may seguridad sa antas ng row. Ang mga subdomain ng isang kliyente ay nabibilang sa organisasyon ng kliyente na iyon, hindi sa isang nakabahaging bucket na kailangan mong bantayan ayon sa kumbensyon.
Mag-deploy, mag-update, at mamahala ng maraming site sa isang kilos sa halip na ulitin ang ginagawa mo kada site.
Ang lahat ngnasa dashboard ay nasa public API, na ginawa mula sa OpenAPI specification. Imaneho ang paglikha ng subdomain mula sa isang org-scoped API key, sa CLI, Terraform, o isang AI tool sa pamamagitan ng aming MCP server.
Ang mga pribilehiyo at administratibong aksyon ay naka-audit-log, at kinokontrol ng role-based access control kung sino sa iyong koponan ang maaaring gumawa ng alin. Makikita mo kung sino ang gumawa, nagbago, o nag-alis ng host.
Oo. Dahil ang bawat subdomain ay tumatakbo bilang isang ganap at hiwalay na nakahiwalay na site na may sarili nitong stack, database, cache, at mga backup, kumukuha ito ng puwang ng site sa iyong plan sa parehong paraan ng isang pangunahing domain. Ang mga plan ay ibinebenta ayon sa bilang ng mga site na saklaw ng mga ito, kaya ang pagdaragdag ng isang subdomain site ay pareho sa accounting ng pagdaragdag ng iba pang site.
Oo, at talagang independiyente sila. Ang bawat subdomain ay sarili nitong rekord ng site na may sariling blueprint, kaya hindi kailangang magkatugma ang mga stack: ang WordPress sa pangunahing domain, WooCommerce sa shop, isang Node.js app sa app, at isang static site sa docs ay karaniwang setup dito kaysa sa isang espesyal na kaso. Maaari silang nasa iba't ibang makina, magpatakbo ng iba't ibang runtime at iba't ibang bersyon ng PHP o Node, at ma-deploy, ma-stage, ma-backup, at ma-roll back ayon sa sarili nilang mga iskedyul. Walang anuman sa isa ang naglilimita sa iba maliban sa pagbabahagi ng pangalan ng domain.
Sakop sila nang awtomatiko sa alinmang paraan. Maaari kang maglabas ng wildcard certificate na sumasaklaw sa bawat host sa ilalim ng domain nang sabay-sabay, o maglabas ng mga sertipiko sa bawat host kung nais mong panatilihing hiwalay ang mga ito. Libre ang mga sertipiko ng Let's Encrypt, awtomatikong inisyu at nire-renew, at maaari kang mag-upload ng custom na sertipiko sa halip kung mayroon ka nito.
Huwag naming ipapayo iyon, at hindi namin ito ibebenta nang ganoon. Ang bawat subdomain ay nagbabahagi ng isang registrable domain, at sa ilalim ng isang wildcard certificate ay isang shared certificate na ang pag-iisyu ay lumalabas sa mga pampublikong Certificate Transparency log, kaya ang mga host ay madaling maiugnay sa isa't isa ng sinumang titingin. Para sa trabaho kung saan ang mga site ay hindi dapat magkakaugnay, gumamit ng magkakahiwalay na registrable domain sa aming Footprint-Free line, na sadyang ininhinyero para rito na may mga pool ng CDN at DNS account, mga pinamamahalaang footprint, at paghahatid ng static-HTML.
Ang plataporma ay binuo upang pigilan ito sa halip na hayaang kumalat. Nililimitahan ng CloudLinux LVE ang CPU, memory, at IO ng bawat site sa sarili nitong kulungan, binibigyan ng CageFS ang bawat site ng hiwalay na view ng filesystem upang nakakulong ang isang breach, at nililimitahan ng MySQL Governor ang load ng database sa bawat site upang ang mga mabibigat na query ng isang site ay hindi magpabagal sa server. Sinusuportahan ito ng malware scanning, isang proactive web application firewall, at mga immutable backup sa bawat site. Containment ang layunin ng disenyo; walang host ang makakapangako na imposibleng mangyari ang isang kompromiso.
Oo. Sadyang pinag-hiwalay ang registrar at DNS. Maaari mong panatilihin ang iyong domain sa kasalukuyang registrar mo at ang iyong zone sa kasalukuyang DNS provider mo, at ituro lang ang record ng subdomain sa amin. Bineberypika namin ang delegasyon at aktibasyon bago ituring na live ang site, kaya agad na lumalabas ang maling type na record sa halip na tahimik na mabigo. Kapag naka-host na rito ang zone ng parent domain, isusulat na namin ang record ng subdomain para sa iyo, kaya wala ka nang kailangang idagdag nang mano-mano.
Sa paraan lamang ng pagkakagawa nito. Ang clone to staging ay lumilikha ng hiwalay na kopya ng live site, kasama ang mga file at database, sa isang staging subdomain na gumagamit ng parehong stack at blueprint bersyon tulad ng production. Kapag nasiyahan ka na, nire-sync ito pabalik ng push-to-live gamit ang database-aware na search-replace. Ang lahat ng iba pa, ang isolation, SSL, caching, backups, at developer access, ay magkatulad sa anumang iba pang site.
Dadalhin mo sila kasama mo. Walang lock-in saanman sa platform: maaari mong makuha ang mga auth code, i-unlock ang mga domain at ilipat ang mga ito palabas, dalhin ang iyong sariling mga CDN at DNS account, at i-export ang iyong mga site. Ang bawat panlabas na provider na ginagamit namin ay nakalagay sa likod ng isang madaling palitan na adapter, na totoo para sa iyo gaya ng para sa amin.
Buong isolation, wildcard SSL, totoong kontrol sa DNS, at one-click staging sa bawat host na idaragdag mo. Magsimula sa isang 14-araw na pagsubok na walang kinakailangang credit card at tingnan kung angkop ito sa iyo bago mag-commit.
Magsimula nang libre