ຄຸນສົມບັດ
ກຳນົດ app, shop, docs ຫຼື staging ໄປຍັງບ່ອນໃດກໍໄດ້ຕາມທີ່ທ່ານຕ້ອງການ ແລະ ຮັບເວັບໄຊແທ້ທີ່ຖືກແຍກອອກຕ່າງຫາກຢ່າງສົມບູນ: ມີສະແຕັກ, ຖານຂໍ້ມູນ, ແຄຊ, ການສຳຮອງຂໍ້ມູນ ແລະ ພື້ນທີ່ຈຳກັດຊັບພະຍາກອນເປັນຂອງຕົນເອງ. ຄວບຄຸມບັນທຶກ DNS ໄດ້ຢ່າງສົມບູນ, SSL ອັດຕະໂນມັດລວມທັງ wildcards, ແລະ staging subdomains ດ້ວຍການຄລິກພຽງຄັ້ງດຽວ. ຄວາມພ້ອມໃຊ້ງານ: ການຈຳກັດການໃຊ້ງານຖານຂໍ້ມູນຕໍ່ເວັບໄຊກຳລັງຢູ່ໃນລະຫວ່າງການພັດທະນາ ແລະ ຍັງບໍ່ພ້ອມໃຫ້ບໍລິການເທື່ອ. ສິ່ງອື່ນໆທັງໝົດທີ່ອະທິບາຍໄວ້ຢູ່ນີ້ພ້ອມໃຊ້ງານແລ້ວໃນມື້ນີ້.
ຢູ່ໃນໂຮສສ່ວນໃຫຍ່, ຊັບໂດເມນແມ່ນໄດເຣັກທໍຣີທີ່ມີກົດລະບຽບການຂຽນຄືນໃໝ່ຢູ່ຕໍ່ໜ້າ. ຢູ່ທີ່ນີ້, ມັນແມ່ນບັນທຶກເວັບໄຊລະດັບສູງທີ່ມີເວີຊັນພິມຂຽວຂອງຕົນເອງ, ການຈັດວາງສະເພາະຢູ່ໃນກຸ່ມເຊີບເວີ ແລະ ຂອບເຂດການແຍກຕົວຂອງຕົນເອງ. ທຸກສິ່ງທີ່ທ່ານສາມາດເຮັດກັບໂດເມນຫຼັກໄດ້, ທ່ານກໍສາມາດເຮັດກັບຊັບໂດເມນໄດ້ເຊັ່ນກັນ.
ແຕ່ລະເວັບໄຊໂດເມນຍ່ອຍແມ່ນສ້າງຂຶ້ນຈາກແບບແຜນທີ່ມີເວີຊັນ ແລະ ເຮັດວຽກໃນປະເພດສະແຕັກ ແລະ runtime ຂອງຕົນເອງ: WordPress ທີ່ຖືກຈັດການ, WooCommerce, PHP, HTML ຄົງທີ່ ຫຼື Node. ໂດເມນຍ່ອຍ docs ຂອງທ່ານສາມາດເປັນ HTML ຄົງທີ່ ໃນຂະນະທີ່ຮາກເຮັດວຽກ WordPress, ໂດຍບໍ່ມີການຫຼຸດຜ່ອນມາດຕະຖານລະຫວ່າງພວກມັນ.
ຖານຂໍ້ມູນ MariaDB ຕໍ່ເວັບໄຊ, ການເກັບແຄຊ໌ເຕັມໜ້າ LiteSpeed LSCache ແລະ ແຄຊ໌ວັດຖຸ Redis ຫຼື Memcached ຕໍ່ເວັບໄຊ. ບໍ່ມີສິ່ງໃດຖືກແບ່ງປັນກັບເວັບໄຊຫຼັກ, ດັ່ງນັ້ນໂດເມນຍ່ອຍທີ່ເຮັດວຽກໜັກຈຶ່ງບໍ່ສາມາດລຶບແຄຊ໌ຂອງເວັບໄຊຫຼັກ ຫຼື ເຮັດໃຫ້ການສອບຖາມຂໍ້ມູນແອອັດໄດ້.
CloudLinux LVE ຈຳກັດ CPU, RAM, IO, IOPS ແລະ ຂະບວນການເຂົ້າເຖິງຕໍ່ເວັບໄຊ, CageFS ມອບມຸມມອງລະບົບໄຟລ໌ສະເພາະໃຫ້ແຕ່ລະເວັບໄຊ, ແລະ MySQL Governor ຄວບຄຸມການໂຫຼດຖານຂໍ້ມູນຕໍ່ເວັບໄຊ. ຊັບໂດເມນທີ່ເຮັດວຽກຜິດປົກກະຕິຈະຖືກກັກກັນໄວ້ພາຍໃນກົງຂອງມັນເອງ.
ການສຳຮອງຂໍ້ມູນລາຍວັນທີ່ຖືກເກັບຮັກສາໄວ້ເປັນເວລາ 30 ວັນ ພ້ອມດ້ວຍການກູ້ຄືນດ້ວຍການຄລິກພຽງຄັ້ງດຽວ ສຳລັບແຕ່ລະເວັບໄຊ. ທ່ານສາມາດຍ້ອນກັບໂດເມນຍ່ອຍໄປສູ່ສະພາບຂອງມື້ວານນີ້ໄດ້ ໂດຍບໍ່ຕ້ອງແຕະຕ້ອງເວັບໄຊຫຼັກ ຫຼື ເວັບໄຊອື່ນໆ ທີ່ກ່ຽວຂ້ອງ.
ໂດເມນຍ່ອຍແມ່ນບັນຫາ DNS ກ່ອນທີ່ມັນຈະເປັນບັນຫາການໂຮສຕິ້ງ, ດັ່ງນັ້ນຊັ້ນ DNS ຈຶ່ງຖືກສະແດງອອກມາຢ່າງຖືກຕ້ອງ ແທນທີ່ຈະຖືກເຊື່ອງໄວ້ທາງຫຼັງແບບຟອມທີ່ມີສອງຊ່ອງຂໍ້ມູນ.
ທຸກໆໂດເມນທີ່ສາມາດລົງທະບຽນໄດ້ທີ່ທ່ານໂຮສ ຈະໄດ້ຮັບເຂດ DNS ທີ່ຈັດການຜ່ານລະບົບເຊື່ອມຕໍ່ DNS driver ຂອງພວກເຮົາ. ທ່ານຈະໄດ້ຮັບການດຳເນີນການ CRUD ຂອງບັນທຶກ ສຳລັບທຸກປະເພດບັນທຶກທີ່ທ່ານຄາດຫວັງ ດັ່ງນັ້ນການເພີ່ມ app, shop, docs, mail ຫຼື ໂຮສ wildcard ຈຶ່ງເປັນພຽງການແກ້ໄຂບັນທຶກເທົ່ານັ້ນ ບໍ່ແມ່ນການເປີດປີ້ແຈ້ງບັນຫາ. ສະຖານະຂອງເຂດຈະຖືກປັບໃຫ້ກົງກັນແບບ idempotent ກັບຜູ້ໃຫ້ບໍລິການ ຊຶ່ງໝາຍຄວາມວ່າການປ່ຽນແປງທີ່ຖືກນຳໃຊ້ພຽງເຄິ່ງໜຶ່ງ ຫຼື ການແກ້ໄຂທີ່ລອງໃໝ່ ຈະລວມເຂົ້າສູ່ສະຖານະທີ່ທ່ານໄດ້ຮ້ອງຂໍ ແທນທີ່ຈະປ່ອຍໃຫ້ເຂດຂອງທ່ານຢູ່ໃນສະຖານະເຄິ່ງກາງທີ່ບໍ່ຊັດເຈນ.
ຜູ້ໃຫ້ບໍລິການຈົດທະບຽນ ແລະ DNS ໄດ້ຖືກແຍກອອກຈາກກັນໂດຍເຈດຕະນາ: ທ່ານສາມາດຈົດທະບຽນໂດເມນກັບພວກເຮົາ ແລະ ຮັກສາ DNS ໄວ້ບ່ອນອື່ນ, ຫຼື ຮັກສາໂດເມນໄວ້ກັບຜູ້ໃຫ້ບໍລິການຈົດທະບຽນປະຈຸບັນຂອງທ່ານ ແລ້ວພຽງແຕ່ຊີ້ໂດເມນຍ່ອຍມາຍັງພວກເຮົາ. ພວກເຮົາກວດສອບການມອບໝາຍ ແລະ ການເປີດໃຊ້ງານ nameserver ກ່ອນທີ່ພວກເຮົາຈະກຳນົດວ່າໂດເມນນັ້ນເປີດໃຊ້ງານຈິງ, ດັ່ງນັ້ນທ່ານຈຶ່ງສາມາດຮັບຮູ້ໄດ້ວ່າບັນທຶກມີຂໍ້ຜິດພາດຈາກແພລດຟອມ ແທນທີ່ຈະຮູ້ຈາກລູກຄ້າ.
ໂດເມນຍ່ອຍທີ່ຊ້າ ຫຼື ສະແດງການແຈ້ງເຕືອນໃບຢັ້ງຢືນ ແມ່ນຮ້າຍແຮງກວ່າການບໍ່ມີໂດເມນຍ່ອຍເລີຍ, ດັ່ງນັ້ນ ເສັ້ນທາງການຈັດສົ່ງຈຶ່ງເປັນເສັ້ນທາງດຽວກັນກັບທີ່ໂດເມນຫຼັກໄດ້ຮັບ.
ໃບຢັ້ງຢືນ Let's Encrypt ແມ່ນອອກໃຫ້ ແລະ ຕໍ່ອາຍຸໂດຍອັດຕະໂນມັດ. ໃຊ້ໃບຢັ້ງຢືນ wildcard ເພື່ອກວມເອົາທຸກ subdomain ພ້ອມກັນ, ໃບຢັ້ງຢືນສະເພາະແຕ່ລະໂຮສບ່ອນທີ່ທ່ານຕ້ອງການແຍກພວກມັນອອກ, ຫຼື ອັບໂຫຼດໃບຢັ້ງຢືນແບບກຳນົດເອງຂອງທ່ານເອງ.
ທຸກໆເວັບໄຊແມ່ນໃຫ້ບໍລິການໂດຍ LiteSpeed ພ້ອມເປີດໃຊ້ງານ HTTP/3, ດັ່ງນັ້ນໂດເມນຍ່ອຍຈຶ່ງໄດ້ຮັບປະສິດທິພາບລະດັບການເຊື່ອມຕໍ່ດຽວກັບໂດເມນຫຼັກ ແທນທີ່ຈະເປັນໂຮສຕ໌ສະເໝືອນຊັ້ນສອງ.
ການເກັບແຄຊ໌ເຕັມໜ້າດ້ວຍ LSCache ພ້ອມກັບແຄຊ໌ວັດຖຸ Redis ຕໍ່ເວັບໄຊ, ໂດຍມີການລຶບລ້າງທີ່ປະສານງານກັນຈາກແຜງໜ້າປັດ ຫຼື ຈາກພາຍໃນ WordPress. ການລຶບລ້າງເວັບໄຊຫຼັກຈະບໍ່ລຶບແຄຊ໌ຂອງໂດເມນຍ່ອຍຂອງທ່ານ.
ນຳໃຊ້ຜ່ານ CDN ຂອງພວກເຮົາ ແລະ ກຸ່ມບັນຊີ Cloudflare ຫຼື ເຊື່ອມຕໍ່ບັນຊີຂອງທ່ານເອງ ແລະ ເລືອກບັນຊີທີ່ເວັບໄຊໃດໜຶ່ງຈະຖືກນຳໃຊ້. ການຈັດສົ່ງແມ່ນການຕັດສິນໃຈຂອງທ່ານ, ບໍ່ແມ່ນສິ່ງທີ່ພວກເຮົາຕັດສິນໃຈແທນທ່ານ.
ເຫດຜົນທົ່ວໄປທີ່ສຸດທີ່ຕ້ອງການຊັບໂດເມນ ແມ່ນເພື່ອໃຫ້ມີພື້ນທີ່ທີ່ປອດໄພໃນການທົດລອງ ແລະ ສ້າງສິ່ງຕ່າງໆໂດຍບໍ່ຕ້ອງກັງວົນ. ເສັ້ນທາງດັ່ງກ່າວໄດ້ຖືກສ້າງຂຶ້ນມາພ້ອມໃຊ້ງານ ແລະ ເປີດໃຫ້ໃຊ້ງານໂດຍບໍ່ມີຂໍ້ຈຳກັດໃນແພັກເກດ Mainstream.
ການໂຄລນໄປຍັງ staging ຈະສ້າງສໍາເນົາທີ່ແຍກຕ່າງຫາກຂອງເວັບໄຊຕົວຈິງໄວ້ໃນ subdomain ຂອງ staging ໂດຍທີ່ໄຟລ໌ ແລະ ຖານຂໍ້ມູນຍັງຄົບຖ້ວນ, ໃນ stack ແລະ ເວີຊັນ blueprint ດຽວກັນກັບ production. ທ່ານເຮັດວຽກໃນສໍາເນົານັ້ນດ້ວຍຊຸດເຄື່ອງມືຄົບຊຸດ: jailed SSH ແລະ SFTP, wp-cli, ໂປຣແກຣມແກ້ໄຂ VS Code ຜ່ານບຣາວເຊີ, phpMyAdmin ຫຼື Adminer, cron ຕໍ່ແຕ່ລະເວັບໄຊ ແລະ ຕົວແປສະພາບແວດລ້ອມ.
ເມື່ອການປ່ຽນແປງໄດ້ຮັບການຢືນຢັນແລ້ວ, ການນຳຂຶ້ນລະບົບຈິງຈະດຳເນີນການຊິ້ງຂໍ້ມູນທີ່ຮັບຮູ້ຖານຂໍ້ມູນກັບຄືນສູ່ສະພາບແວດລ້ອມການໃຊ້ງານຈິງ. ທ່ານສາມາດເລືອກໄຟລ໌, ຖານຂໍ້ມູນ ຫຼື ທັງສອງຢ່າງໄດ້, ແລະ ລະບົບຈະຈັດການການຊອກຫາ ແລະ ປ່ຽນແທນໃຫ້ທ່ານໂດຍອັດຕະໂນມັດ ເພື່ອໃຫ້ URL ໃນເນື້ອຫາຂອງທ່ານປ່ຽນຕາມເວັບໄຊ ແທນທີ່ຈະຊີ້ກັບຄືນໄປຫາໂຮສທົດສອບ. ເນື່ອງຈາກການຈັດສັນຊັບພະຍາກອນ, ການໂຄລນ ແລະ ການນຳໃຊ້ງານ ທັງໝົດລ້ວນແຕ່ເຮັດວຽກເປັນຂະບວນການ Temporal ທີ່ມີຄວາມທົນທານ ພ້ອມດ້ວຍການລອງໃໝ່ແຕ່ລະຂັ້ນຕອນ ແລະ ການຊົດເຊີຍ, ຄວາມຜິດພາດໃນລະຫວ່າງຂະບວນການຈະຍົກເລີກວຽກທີ່ເຮັດໄປບາງສ່ວນ ແທນທີ່ຈະປ່ອຍໃຫ້ທ່ານມີເວັບໄຊທີ່ຖືກໂຄລນພຽງແຕ່ເຄິ່ງດຽວ.
ພວກເຮົາຂໍບອກທ່ານເລື່ອງນີ້ໄວ້ກ່ອນ ດີກວ່າຂາຍສິ່ງທີ່ຈະສົ່ງຜົນເສຍຕໍ່ສິ່ງທີ່ທ່ານກຳລັງພະຍາຍາມເຮັດ.
ໂດເມນຍ່ອຍແມ່ນຄຳຕອບທີ່ຖືກຕ້ອງສຳລັບການຈັດໂຄງສ້າງແບຣນດຽວ: ແອັບ, ຮ້ານຄ້າ, ເວັບໄຊເອກະສານ, ພອດທໍລູກຄ້າ, ສະພາບແວດລ້ອມສະເຕຈິງສຳລັບລູກຄ້າແຕ່ລະຄົນ. ພວກມັນເປັນຄຳຕອບທີ່ບໍ່ຖືກຕ້ອງສຳລັບເຄືອຂ່າຍບລັອກສ່ວນຕົວ. ທຸກໆໂດເມນຍ່ອຍໃຊ້ໂດເມນທີ່ສາມາດລົງທະບຽນໄດ້ຮ່ວມກັນ, ດັ່ງນັ້ນຜູ້ໃດກໍຕາມທີ່ຊອກຫາທີ່ຢູ່ຂອງອັນໃດອັນໜຶ່ງກໍຈະຮູ້ໄດ້ຢ່າງແນ່ນອນວ່າໃຜເປັນເຈົ້າຂອງສ່ວນທີ່ເຫຼືອ. ພາຍໃຕ້ໃບຢັ້ງຢືນ wildcard ພວກມັນຍັງໃຊ້ໃບຢັ້ງຢືນຮ່ວມກັນນຳອີກ, ແລະ ການອອກໃບຢັ້ງຢືນຈະຖືກເຜີຍແຜ່ລົງໃນບັນທຶກ Certificate Transparency ສາທາລະນະ, ດັ່ງນັ້ນໂຮສພາຍໃຕ້ໂດເມນທີ່ໃຊ້ຮ່ວມກັນຈຶ່ງສາມາດຖືກນັບ ແລະ ກວດສອບໄດ້ໂດຍໃຜກໍຕາມທີ່ສົນໃຈຢາກເບິ່ງ. ນັ້ນເປັນຄຸນສົມບັດຂອງລະບົບ PKI ເວັບສາທາລະນະ ແລະ DNS, ບໍ່ແມ່ນຂອງແພລດຟອມພວກເຮົາ, ແລະ ບໍ່ມີການຕັ້ງຄ່າໂຮສຕິງໃດໆທີ່ສາມາດປ່ຽນແປງມັນໄດ້.
ດັ່ງນັ້ນ ຊັບໂດເມນຈຶ່ງຢູ່ໃນສາຍ Mainstream ແລະ Agency ຂອງພວກເຮົາ, ບໍ່ແມ່ນສາຍ Footprint-Free. ຖ້າຄວາມຕ້ອງການຂອງທ່ານຄືເວັບໄຊຕ່າງໆຕ້ອງບໍ່ສາມາດເຊື່ອມໂຍງຫາກັນໄດ້, ທ່ານຈໍາເປັນຕ້ອງມີໂດເມນທີ່ສາມາດລົງທະບຽນໄດ້ແຍກຕ່າງຫາກຢູ່ໃນສາຍຜະລິດຕະພັນທີ່ບໍ່ມີ footprint, ເຊິ່ງກຸ່ມບັນຊີ CDN ແລະ DNS, ການຈັດການ footprint ແລະ ການສົ່ງ static-HTML ມີໄວ້ເພື່ອຕັດຮູບແບບດັ່ງກ່າວໂດຍສະເພາະ. ທັງສອງຢ່າງເຮັດວຽກຢູ່ເທິງເຄື່ອງຈັກດຽວກັນ ແລະ ແຜງໜ້າປັດດຽວກັນ, ດັ່ງນັ້ນການເລືອກຢ່າງຖືກຕ້ອງຈຶ່ງບໍ່ໄດ້ເຮັດໃຫ້ທ່ານເສຍຄວາມສະດວກສະບາຍແຕ່ຢ່າງໃດ.
ຕົວແທນ ແລະ ຜູ້ຂາຍຕໍ່ໃຊ້ໂດເມນຍ່ອຍໃນປະລິມານຫຼາຍ: ໂຮສຕ໌ສະເຕຈິງໜຶ່ງຕໍ່ລູກຄ້າໜຶ່ງຄົນ, ໂຮສຕ໌ສະແດງຕົວຢ່າງໜຶ່ງຕໍ່ໂຄງການໜຶ່ງ, ພອດທັລໜຶ່ງຕໍ່ບັນຊີໜຶ່ງ. ແພລດຟອມນີ້ຖືກສ້າງຂຶ້ນມາເພື່ອຮູບແບບການເຮັດວຽກດັ່ງກ່າວ.
ອົງກອນຕ່າງໆ ຖືກຈັດຮຽງແບບຕົ້ນໄມ້, ຈາກຕົວແທນຈຳໜ່າຍ ໄປຫາລູກຄ້າ ຈົນຮອດເວັບໄຊ, ແລະ ທຸກໆ ບັນທຶກແມ່ນຖືກກຳນົດຂອບເຂດ ແລະ ບັງຄັບໃຊ້ຢູ່ຖານຂໍ້ມູນດ້ວຍຄວາມປອດໄພລະດັບແຖວ. ໂດເມນຍ່ອຍຂອງລູກຄ້າແມ່ນຂຶ້ນກັບອົງກອນຂອງລູກຄ້ານັ້ນ, ບໍ່ແມ່ນຂຶ້ນກັບບ່ອນເກັບຂໍ້ມູນຮ່ວມກັນທີ່ທ່ານຕ້ອງຄອຍຄວບຄຸມຕາມທຳນຽມປະຕິບັດ.
ນຳໃຊ້, ອັບເດດ ແລະ ຈັດການຫຼາຍເວັບໄຊໃນຄຳສັ່ງດຽວ ແທນທີ່ຈະຕ້ອງເຮັດຊ້ຳກັນສຳລັບແຕ່ລະເວັບໄຊ.
ທຸກຢ່າງໃນໜ້າປັດແມ່ນມີຢູ່ໃນ API ສາທາລະນະ, ເຊິ່ງສ້າງຂຶ້ນຈາກຂໍ້ກຳນົດສະເພາະຂອງ OpenAPI. ຈັດການການສ້າງໂດເມນຍ່ອຍຈາກລະຫັດ API ລະດັບອົງກອນ, CLI, Terraform ຫຼື ເຄື່ອງມື AI ຜ່ານເຊີບເວີ MCP ຂອງພວກເຮົາ.
ການກະທຳທີ່ມີສິດທິພິເສດ ແລະ ການບໍລິຫານແມ່ນຖືກບັນທຶກໄວ້ໃນບັນທຶກການກວດສອບ, ແລະ ການຄວບຄຸມການເຂົ້າເຖິງຕາມບົດບາດຈະກຳນົດວ່າໃຜໃນທີມຂອງທ່ານສາມາດເຮັດຫຍັງໄດ້ແດ່. ທ່ານສາມາດເບິ່ງເຫັນໄດ້ວ່າໃຜເປັນຜູ້ສ້າງ, ປ່ຽນແປງ ຫຼື ລຶບໂຮສຕ໌ອອກ.
ແມ່ນແລ້ວ. ເນື່ອງຈາກແຕ່ລະໂດເມນຍ່ອຍເຮັດວຽກເປັນເວັບໄຊທີ່ແຍກຕ່າງຫາກຢ່າງສົມບູນ ໂດຍມີສະແຕັກ, ຖານຂໍ້ມູນ, ແຄຊ ແລະ ການສຳຮອງຂໍ້ມູນຂອງຕົນເອງ, ມັນຈຶ່ງໃຊ້ຊ່ອງເວັບໄຊໃນແພັກເກດຂອງທ່ານເຊັ່ນດຽວກັບໂດເມນຫຼັກ. ແພັກເກດຕ່າງໆແມ່ນຂາຍຕາມຈຳນວນເວັບໄຊທີ່ຮອງຮັບ, ດັ່ງນັ້ນການເພີ່ມເວັບໄຊໂດເມນຍ່ອຍຈຶ່ງຖືກຄິດໄລ່ຄືກັນກັບການເພີ່ມເວັບໄຊອື່ນໆ.
ແມ່ນແລ້ວ, ແລະ ພວກມັນເປັນອິດສະຫຼະຕໍ່ກັນຢ່າງແທ້ຈິງ. ແຕ່ລະໂດເມນຍ່ອຍແມ່ນບັນທຶກເວັບໄຊຂອງຕົນເອງທີ່ມີແບບແຜນ (blueprint) ຂອງຕົນເອງ, ດັ່ງນັ້ນ stacks ຈຶ່ງບໍ່ຈຳເປັນຕ້ອງຄືກັນ: WordPress ຢູ່ໃນໂດເມນຫຼັກ, WooCommerce ຢູ່ໃນ shop, ແອັບ Node.js ຢູ່ໃນ app ແລະ ເວັບໄຊສະແຕຕິກຢູ່ໃນ docs ແມ່ນການຕິດຕັ້ງປົກກະຕິຢູ່ທີ່ນີ້ ແທນທີ່ຈະເປັນກໍລະນີພິເສດ. ພວກມັນສາມາດຢູ່ເທິງເຄື່ອງທີ່ແຕກຕ່າງກັນ, ໃຊ້ runtimes ທີ່ແຕກຕ່າງກັນ ແລະ ເວີຊັນ PHP ຫຼື Node ທີ່ແຕກຕ່າງກັນ, ແລະ ສາມາດຖືກ deploy, stage, ສຳຮອງຂໍ້ມູນ ແລະ ຍ້ອນກັບ (rollback) ຕາມຕາຕະລາງເວລາຂອງພວກມັນເອງ. ບໍ່ມີສິ່ງໃດກ່ຽວກັບອັນໜຶ່ງທີ່ຈະຈຳກັດອີກອັນໜຶ່ງ ນອກເໜືອໄປຈາກການໃຊ້ຊື່ໂດເມນຮ່ວມກັນ.
ພວກມັນໄດ້ຮັບການປົກປ້ອງໂດຍອັດຕະໂນມັດບໍ່ວ່າຈະເລືອກວິທີໃດ. ທ່ານສາມາດອອກໃບຢັ້ງຢືນ wildcard ທີ່ກວມເອົາທຸກໂຮສຕ໌ພາຍໃຕ້ໂດເມນໃນຄັ້ງດຽວ, ຫຼື ອອກໃບຢັ້ງຢືນແຍກຕາມແຕ່ລະໂຮສຕ໌ໃນບ່ອນທີ່ທ່ານຕ້ອງການແຍກພວກມັນອອກຈາກກັນ. ໃບຢັ້ງຢືນ Let's Encrypt ແມ່ນຟຣີ, ຖືກອອກໃຫ້ ແລະ ຕໍ່ອາຍຸໂດຍອັດຕະໂນມັດ, ແລະ ທ່ານສາມາດອັບໂຫຼດໃບຢັ້ງຢືນແບບກຳນົດເອງແທນໄດ້ຫາກທ່ານມີຢູ່ແລ້ວ.
ພວກເຮົາຂໍແນະນຳບໍ່ໃຫ້ເຮັດແນວນັ້ນ, ແລະ ພວກເຮົາຈະບໍ່ຂາຍມັນໃນຮູບແບບນັ້ນ. ທຸກໆ subdomain ໃຊ້ໂດເມນທີ່ສາມາດລົງທະບຽນໄດ້ຮ່ວມກັນ, ແລະ ພາຍໃຕ້ໃບຢັ້ງຢືນ wildcard ແມ່ນໃຊ້ໃບຢັ້ງຢືນຮ່ວມກັນເຊິ່ງການອອກໃບຢັ້ງຢືນດັ່ງກ່າວຈະປະກົດໃນບັນທຶກສາທາລະນະຂອງ Certificate Transparency, ດັ່ງນັ້ນທຸກຄົນທີ່ກວດເບິ່ງຈຶ່ງສາມາດເຊື່ອມໂຍງ host ເຫຼົ່ານັ້ນເຂົ້າຫາກັນໄດ້. ສຳລັບວຽກທີ່ເວັບໄຊຕ້ອງບໍ່ສາມາດເຊື່ອມໂຍງຫາກັນໄດ້, ກະລຸນາໃຊ້ໂດເມນທີ່ສາມາດລົງທະບຽນໄດ້ແຍກຕ່າງຫາກຢູ່ໃນສາຍບໍລິການ Footprint-Free ຂອງພວກເຮົາ, ເຊິ່ງໄດ້ຮັບການອອກແບບມາໂດຍສະເພາະສຳລັບຈຸດປະສົງນັ້ນ ພ້ອມດ້ວຍກຸ່ມບັນຊີ CDN ແລະ DNS, ຮ່ອງຮອຍ (footprints) ທີ່ໄດ້ຮັບການຈັດການ ແລະ ການສົ່ງມອບ HTML ແບບຄົງທີ່.
ແພລັດຟອມນີ້ຖືກສ້າງຂຶ້ນມາເພື່ອຄວບຄຸມມັນ ຫຼາຍກວ່າທີ່ຈະປ່ອຍໃຫ້ມັນແຜ່ລາມ. CloudLinux LVE ຈຳກັດ CPU, ໜ່ວຍຄວາມຈຳ ແລະ IO ຂອງແຕ່ລະເວັບໄຊໄວ້ພາຍໃນພື້ນທີ່ສະເພາະຂອງຕົນເອງ, CageFS ໃຫ້ມຸມມອງລະບົບໄຟລ໌ທີ່ແຍກຕ່າງຫາກແກ່ແຕ່ລະເວັບໄຊ ເພື່ອໃຫ້ການບຸກລຸກຖືກຄວບຄຸມໄວ້ໄດ້, ແລະ MySQL Governor ຈະຈຳກັດການໂຫຼດຖານຂໍ້ມູນຕໍ່ແຕ່ລະເວັບໄຊ ເພື່ອບໍ່ໃຫ້ການສອບຖາມຂໍ້ມູນທີ່ໜັກໜ່ວງຂອງເວັບໄຊໃດໜຶ່ງເຮັດໃຫ້ເຊີບເວີຊ້າລົງ. ການສະແກນມັນແວ, ໄຟວໍແອັບພລິເຄຊັນເວັບແບບເຊີງຮຸກ ແລະ ການສຳຮອງຂໍ້ມູນທີ່ບໍ່ສາມາດແກ້ໄຂໄດ້ຕໍ່ເວັບໄຊ ຈະຊ່ວຍສະໜັບສະໜູນສິ່ງດັ່ງກ່າວ. ການຄວບຄຸມບໍ່ໃຫ້ແຜ່ລາມຄືເປົ້າໝາຍໃນການອອກແບບ; ບໍ່ມີຜູ້ໃຫ້ບໍລິການໂຮສຕິ້ງໃດສາມາດສັນຍາໄດ້ວ່າ ຈະບໍ່ມີການຖືກບຸກລຸກເລີຍ.
ແມ່ນແລ້ວ. ຜູ້ຮັບຈົດທະບຽນ ແລະ DNS ໄດ້ຖືກແຍກອອກຈາກກັນໂດຍເຈດຕະນາ. ທ່ານສາມາດຮັກສາໂດເມນຂອງທ່ານໄວ້ກັບຜູ້ຮັບຈົດທະບຽນປະຈຸບັນ ແລະ ຮັກສາໂຊນຂອງທ່ານໄວ້ກັບຜູ້ໃຫ້ບໍລິການ DNS ປະຈຸບັນຂອງທ່ານໄດ້ ແລະ ພຽງແຕ່ຊີ້ບັນທຶກຂອງໂດເມນຍ່ອຍມາຍັງພວກເຮົາ. ພວກເຮົາກວດສອບການມອບສິດ ແລະ ການເປີດໃຊ້ງານກ່ອນທີ່ຈະຖືວ່າເວັບໄຊທ໌ໃຊ້ງານໄດ້ແທ້, ດັ່ງນັ້ນບັນທຶກທີ່ພິມຜິດຈະປະກົດຂຶ້ນທັນທີແທນທີ່ຈະລົ້ມເຫຼວໄປແບບງຽບໆ. ເມື່ອໂຊນຂອງໂດເມນຫຼັກຖືກໂຮສຢູ່ນີ້ແລ້ວ, ພວກເຮົາຈະຂຽນບັນທຶກຂອງໂດເມນຍ່ອຍລົງໃນນັ້ນໃຫ້ທ່ານແທນ, ດັ່ງນັ້ນຈຶ່ງບໍ່ມີສິ່ງໃດທີ່ທ່ານຕ້ອງເພີ່ມດ້ວຍຕົນເອງ.
ພຽງແຕ່ແຕກຕ່າງກັນໃນວິທີການສ້າງຂຶ້ນເທົ່ານັ້ນ. ການ Clone ໄປຍັງ staging ຈະສ້າງສໍາເນົາທີ່ແຍກຕ່າງຫາກຂອງເວັບໄຊຕົວຈິງ, ລວມທັງໄຟລ໌ ແລະ ຖານຂໍ້ມູນ, ໄວ້ໃນໂດເມນຍ່ອຍ staging ທີ່ໃຊ້ stack ແລະ ເວີຊັນ blueprint ດຽວກັນກັບ production. ເມື່ອທ່ານພໍໃຈແລ້ວ, push-to-live ຈະຊິງຄ໌ມັນກັບຄືນດ້ວຍການຄົ້ນຫາ ແລະ ແທນທີ່ທີ່ຮອງຮັບຖານຂໍ້ມູນ. ສ່ວນອື່ນໆທັງໝົດ, ການແຍກລະບົບ, SSL, ການເຮັດແຄຊ, ການສໍາຮອງຂໍ້ມູນ ແລະ ການເຂົ້າເຖິງຂອງນັກພັດທະນາ, ແມ່ນຄືກັນກັບເວັບໄຊອື່ນໆທຸກປະການ.
ທ່ານສາມາດເອົາພວກມັນໄປກັບທ່ານໄດ້. ບໍ່ມີການຜູກຂາດຢູ່ບ່ອນໃດໃນແພລດຟອມ: ທ່ານສາມາດດຶງເອົາລະຫັດການກວດສອບຄວາມຖືກຕ້ອງ, ປົດລັອກໂດເມນ ແລະ ໂອນພວກມັນອອກ, ນໍາໃຊ້ບັນຊີ CDN ແລະ DNS ຂອງທ່ານເອງ, ແລະ ສົ່ງອອກເວັບໄຊຂອງທ່ານໄດ້. ທຸກໆຜູ້ໃຫ້ບໍລິການພາຍນອກທີ່ພວກເຮົາໃຊ້ແມ່ນຢູ່ເບື້ອງຫຼັງຕົວປັບທີ່ສາມາດປ່ຽນແທນໄດ້, ເຊິ່ງເປັນຄວາມຈິງສໍາລັບທ່ານເຊັ່ນດຽວກັບພວກເຮົາ.
ການແຍກລະບົບຢ່າງສົມບູນ, wildcard SSL, ການຄວບຄຸມ DNS ທີ່ແທ້ຈິງ ແລະ ການສ້າງລະບົບທົດສອບດ້ວຍການຄລິກພຽງຄັ້ງດຽວໃນທຸກໆໂຮສທີ່ທ່ານເພີ່ມ. ເລີ່ມຕົ້ນດ້ວຍການທົດລອງໃຊ້ 14 ວັນໂດຍບໍ່ຕ້ອງໃຊ້ບັດ ແລະ ເບິ່ງຄວາມເໝາະສົມກ່ອນທີ່ທ່ານຈະຕັດສິນໃຈ.
ເລີ່ມຕົ້ນຟຣີ