ARM VPS یا x86 VPS: اصل میں کیا فرق پڑتا ہے؟

ARM VPS پر منتقل ہونے سے کیا تبدیلی آتی ہے

ARM VPS پر وہی Linux اور وہی Nginx چلتا ہے جو x86 VPS پر چلتا ہے، اور عموماً فی core لاگت کم ہوتی ہے۔ منتقلی کا بنیادی خطرہ compatibility ہے۔ x86-64 کے لیے compile کیا گیا پروگرام arm64 پر بالکل نہیں چل سکتا، اس لیے آپ کے stack کے ہر software کے لیے arm64 build دستیاب ہونا چاہیے یا اسے دوبارہ build کرنا ممکن ہونا چاہیے۔

زیادہ تر جدید stacks بغیر کسی اضافی کام کے یہ شرط پوری کر لیتے ہیں۔ مسائل عموماً دو جگہوں پر آتے ہیں: وہ container images جو صرف ایک architecture کے لیے بنائی گئی ہوں، اور closed-source software جس کا arm64 download دستیاب نہ ہو۔ ذیل کے commands آپ کو instance کے لیے ادائیگی کرنے سے پہلے اپنے stack کے بارے میں دونوں سوالوں کا جواب دیتے ہیں۔ اگر آپ ابھی یہ طے کر رہے ہیں کہ آپ کو کس قسم کا server درکار ہے، تو پہلے VPS کیا ہے اور یہ shared hosting سے کیسے مختلف ہے پڑھیں۔

arm64، aarch64، amd64: کون سا نام کیا معنی رکھتا ہے

کسی بھی کام سے پہلے ہر instance پر یہ کمانڈ چلائیں۔

uname -m
dpkg --print-architecture
lscpu | head -n 12
getconf PAGESIZE

ARM مشین پر uname -m، aarch64 دکھاتا ہے، جبکہ Intel یا AMD مشین پر x86_64 دکھاتا ہے۔ انہی دو مشینوں کے لیے dpkg --print-architecture، arm64 اور amd64 دکھاتا ہے۔ دونوں نتائج درست ہیں۔ Linux kernel اور Debian packaging system نے ایک ہی instruction set کے لیے مختلف نام منتخب کیے ہیں۔ اس لیے aarch64 اور arm64 ایک ہی چیز، جبکہ x86_64 اور amd64 دوسری چیز کو ظاہر کرتے ہیں۔ Docker، Debian طرز کے نام استعمال کرتا ہے، اسی لیے image platform linux/arm64 جیسا دکھائی دیتا ہے۔

arm64 پر /proc/cpuinfo میں model name کی سطر موجود نہیں ہوتی۔ اس کے بجائے Features فیلڈ ملتا ہے، اور hardware crypto وہاں aes pmull sha1 sha2 جیسی flags کے طور پر ظاہر ہوتا ہے۔ یہ ARMv8 Cryptographic Extensions ہیں۔ یہ Intel اور AMD کے حصوں میں AES-NI جیسا کام کرتے ہیں۔ یہ TLS (transport layer security) اور disk encryption کو hardware کے ذریعے تیز بناتے ہیں۔ VPS پر AES hardware acceleration کی جانچ میں دونوں architectures پر یہ test کرنے کا طریقہ بیان کیا گیا ہے۔

کنٹینرز پہلے کیوں ناکام ہوتے ہیں، اور error کیسی نظر آتی ہے

ہر Docker image manifest اس architecture کو ریکارڈ کرتا ہے جس کے لیے image build کی گئی ہو۔ ایسی image کو arm64 host پر pull کریں جس میں صرف amd64 manifest ہو، تو pull کامیاب ہو جاتی ہے۔ failure پہلے process کے start ہونے پر ظاہر ہوتی ہے:

WARNING: The requested image's platform (linux/amd64) does not match the detected host platform (linux/arm64/v8) and no specific platform was requested
exec /usr/local/bin/docker-entrypoint.sh: exec format error

exec format error اس kernel کا file چلانے سے انکار ہے، کیونکہ اس کے ELF (executable and linkable format) header میں ایسے machine type کا نام ہے جسے یہ CPU implement نہیں کرتا۔ کوئی setting اسے درست نہیں کر سکتی۔ یہ instructions CPU کے silicon میں موجود نہیں ہیں۔

Deploy کرنے سے پہلے manifest چیک کریں:

docker buildx imagetools inspect nginx:1.27

Output میں manifest list کی ہر image کے لیے ایک Platform: line درج ہوتی ہے، مثلاً linux/amd64 اور linux/arm64۔ اگر linux/arm64 موجود نہ ہو تو یہ tag ARM VPS پر start نہیں ہوگا۔ docker manifest inspect --verbose nginx:1.27 یہی معلومات دکھاتا ہے، لیکن Docker کے مطابق docker manifest ایک experimental command ہے جس کا behaviour releases کے درمیان تبدیل ہو سکتا ہے، اس لیے imagetools کو ترجیح دیں۔

اپنی بنائی ہوئی images کے لیے دونوں architectures کو ایک command میں build کریں اور manifest list push کریں:

docker buildx build --platform linux/amd64,linux/arm64 -t registry.example.com/app:1.4 --push .

ایک host پر foreign architecture کے لیے build کرنے کے لیے kernel کے binfmt_misc handler کے ساتھ QEMU user mode emulation رجسٹر ہونا ضروری ہے:

docker run --privileged --rm tonistiigi/binfmt --install all

Emulation کو build اور test کے لیے استعمال کریں۔ اسے traffic serve کرنے کے لیے استعمال نہ کریں۔ Docker کی اپنی documentation کے مطابق QEMU کے ساتھ emulation "native builds سے بہت سست ہو سکتی ہے، خاص طور پر compilation اور compression یا decompression جیسے compute-heavy tasks میں"، اس لیے ARM instance پر emulated x86 service وہ بچت ختم کر دیتی ہے جس کی وجہ سے آپ نے migration کیا تھا۔ Native case کے لیے host setup دونوں architectures پر یکساں ہے: VPS پر Docker چلانا اس کی وضاحت کرتا ہے، اور existing Compose file اس وقت بغیر تبدیلی کے کام کرتی ہے جب اس میں موجود ہر image کے پاس arm64 manifest ہو۔

کیا مجھے درکار packages arm64 کے لیے دستیاب ہوں گے؟

Ubuntu اور Debian تقریباً پورے archive کو arm64 کے لیے build کرتے ہیں، اس لیے apt install nginx postgresql redis-server دونوں architectures پر یکساں کام کرتا ہے۔ کمی عموماً third-party repositories میں ہوتی ہے۔

ARM instance پر apt سے براہِ راست پوچھیں:

apt-cache policy some-vendor-agent
apt-get install -s some-vendor-agent

apt-cache policy کی reporting Candidate: (none) کا مطلب ہے کہ کوئی بھی enabled repository اس architecture کے لیے اس package کی build شائع نہیں کرتی۔ apt-get install -s install کو simulate کرتا ہے اور کچھ بھی write نہیں کرتا۔ اسی صورت میں یہ E: Unable to locate package پر ختم ہوتا ہے۔

اس کے بعد apt update کا output پڑھیں۔ اسے scroll کر کے نظرانداز نہ کریں۔ اگر vendor repository صرف amd64 کے لیے ہو تو وہ یہ بات واضح کرتی ہے:

N: Skipping acquire of configured file 'main/binary-arm64/Packages' as repository 'https://repo.example.com/apt stable InRelease' doesn't support architecture 'arm64'

Repository configured اور reachable ہے، لیکن اس میں ایسی کوئی چیز موجود نہیں جسے یہ machine install کر سکے۔ Source entry کو بھی خود چیک کریں۔ [arch=amd64] کے ساتھ pinned line کو arm64 host پر skip کر دیا جاتا ہے۔ اس لیے package missing دکھائی دیتا ہے، جبکہ اصل وجہ pin ہوتی ہے۔

کون سے workloads محفوظ ہیں، اور کن کے لیے پہلے جانچ ضروری ہے

Interpreted اور bytecode runtimes بنیادی طور پر قابل انتقال ہوتے ہیں۔ PHP، Python، Ruby اور Node.js، سبھی کو مرکزی distributions میں arm64 packages حاصل ہیں۔ Go اور Rust صرف ایک target مقرر کرکے arm64 کے لیے cross-compile ہو جاتے ہیں۔ LEMP stack، Node API، Nginx کے پیچھے Go binary، یا Postgres database، arm64 پر معمول کے workloads ہیں۔

just in time (JIT) compiler پروگرام کے چلنے کے دوران machine code تیار کرتا ہے، اس لیے اسے target architecture کے لیے code generator درکار ہوتا ہے۔ موجودہ versions میں یہ سہولت موجود ہے۔ Linux پر OpenJDK، .NET، Node.js کے اندر موجود V8 engine، اور PyPy سب arm64 کو support کرتے ہیں۔ اصل خطرہ پرانے pinned versions ہیں۔ اگر deploy script کئی سال پرانا runtime release install کرتی ہے تو اسے قابلِ اعتماد سمجھنے کے بجائے اس release کے notes میں aarch64 support کی تصدیق کریں۔

وہ libraries زیادہ خاموش مسئلہ پیدا کرتی ہیں جن میں ہاتھ سے لکھی ہوئی x86 assembly، یا SSE اور AVX intrinsics شامل ہوں۔ ان میں سے زیادہ تر کے پاس NEON path بھی ہوتا ہے۔ NEON، ARM کا vector instruction set ہے۔ ورنہ plain C fallback موجود ہوتا ہے، اس لیے یہ libraries compile اور run ہو جاتی ہیں۔ Performance، x86 build کے مقابلے میں کسی بھی سمت مختلف ہو سکتی ہے۔ کسی article سے اندازہ لگانے کے بجائے اپنی instance پر اسے measure کریں۔

Closed source software اصل رکاوٹ ہے۔ Vendor monitoring agent، licensed database driver، commercial control panel، یا anti-virus daemon compiled binary کی صورت میں فراہم ہوتا ہے۔ اگر vendor arm64 build جاری نہ کرے تو آپ اس کے بارے میں کچھ نہیں کر سکتے۔ Hosting میں cPanel اور WHM اس کی واضح مثال ہیں۔ اس کی system requirements میں x86_64 درج ہے اور ARM شامل نہیں ہے، اس لیے control panel server کو x86 پر رکھیں۔ یہ معلومات August 2026 میں check کی گئی ہیں، تاہم vendor کے اپنے requirements page پر انہیں دوبارہ پڑھنا مفید ہے۔ اگر صرف یہی چیز آپ کو روک رہی ہے تو VPS پر چلانے کے قابل cPanel alternatives سے شروع کریں، اور ہر alternative کی architecture support اسی طریقے سے check کریں۔

کرنل اور page size: ARM instances میں اب بھی موجود فرق

x86-64 سرور تقریباً ایک دوسرے کے متبادل ہوتے ہیں۔ ARM سرور زیادہ یکساں نہیں ہوتے، اور یہ فرق آپ کی application سے نیچے کی سطح پر موجود ہوتے ہیں۔

Page size وہ فرق ہے جو production environment تک پہنچتا ہے۔ زیادہ تر arm64 kernels میں 4 KiB pages استعمال ہوتے ہیں، جو x86-64 کے برابر ہیں۔ کچھ kernels میں 64 KiB pages استعمال ہوتے ہیں۔ Red Hat Enterprise Linux 8 for aarch64 میں default طور پر 64 KiB page kernel جاری کیا گیا تھا، جبکہ RHEL 9 میں default دوبارہ 4 KiB کر دیا گیا اور بڑے سائز کی ضرورت رکھنے والے workloads کے لیے الگ kernel-64k package برقرار رکھا گیا۔ 64 KiB page size بہت سی چھوٹی mappings والے process کے لیے memory floor بڑھا دیتا ہے، کیونکہ kernel کا فراہم کردہ سب سے چھوٹا chunk سولہ گنا بڑا ہوتا ہے۔ Instance پر getconf PAGESIZE چلائیں اور مفروضہ قائم کرنے کے بجائے حاصل شدہ number پڑھیں۔ Page size واحد kernel فیصلہ نہیں ہے جو آپ تک پہنچتا ہے، کیونکہ provider کا جاری کردہ version یہ بھی طے کرتا ہے کہ کام cores پر کیسے schedule ہوں گے، اور Linux 7.2 میں شامل cache-aware scheduling arm64 اور x86-64 دونوں پر دستیاب ہے۔

چند نسبتاً چھوٹے فرق جاننا بھی مفید ہے۔ arm64 پر operating system CPU microcode package نہیں ہوتا، اس لیے firmware updates آپ کے provider کی طرف سے آتی ہیں، apt سے نہیں۔ ARM سرور UEFI (unified extensible firmware interface) کے ذریعے boot ہوتے ہیں اور اپنے hardware کو ACPI (advanced configuration and power interface) کے ذریعے بیان کرتے ہیں۔ x86 کی کچھ features کا ARM میں کوئی متبادل نہیں ہے، جن میں AMD SEV memory encryption اور Intel GVT-g mediated GPUs شامل ہیں۔

کیا ARM سرور پلیٹ فارم پختہ ہو چکا ہے؟

سافٹ ویئر کے معاملے میں جواب ہاں ہے۔ Debian، Ubuntu، Fedora اور RHEL سبھی first-class arm64 builds جاری کرتے ہیں، اور Docker Hub پر موجود official images معمول کے مطابق multi-arch ہوتی ہیں۔

حالیہ واضح ثبوت Proxmox ہے۔ 5 August 2026 کو Proxmox نے Proxmox Virtual Environment کے پہلے officially supported arm64 edition، version 9.2، کا اعلان کیا۔ یہ edition package repositories اور release lifecycle کو x86-64 edition کے ساتھ مشترک رکھتا ہے۔ یہ Debian 13.5، Linux 7.0، QEMU 11.0، LXC 7.0 اور ZFS 2.4 پر مبنی ہے۔ Configuration اور tooling x86-64 سے مطابقت رکھتے ہیں، سوائے architecture-specific items کے ایک مختصر مجموعے کے۔

اسی announcement میں موجود caveats ضرور پڑھیں، کیونکہ ان سے ظاہر ہوتا ہے کہ officially supported ARM server hardware اب بھی کتنا محدود ہے۔ Proxmox نے پہلے دن NVIDIA Grace اور NVIDIA Vera systems کی validation کی، جو NVIDIA اور Supermicro کے ساتھ Grace Hopper hardware پر مشترکہ testing کے بعد ممکن ہوئی۔ دیگر UEFI-based ARMv8-A اور ARMv9-A hardware کو best-effort support حاصل ہے۔ صرف device tree استعمال کرنے والے single-board computers، جیسے Raspberry Pi، supported نہیں ہیں۔ کوئی guest صرف اپنی architecture کے node پر چلتا ہے۔ Live migration صرف ایک ہی architecture کے nodes کے درمیان کام کرتی ہے۔ Mixed-architecture clusters officially supported نہیں ہیں۔

August 2026 تک یہی حقیقت پسندانہ صورت حال ہے۔ کسی hypervisor vendor کا x86-64 کے برابر lifecycle پر arm64 جاری کرنا اس پلیٹ فارم کے لیے حقیقی پیش رفت ہے۔ پہلے دن supported hardware کی فہرست صرف 2 CPU families پر مشتمل ہے۔

commit کرنے سے پہلے چلانے کے لیے فہرست

1. آزمائشی instance پر uname -m چلائیں اور تصدیق کریں کہ یہ aarch64 دکھاتا ہے۔
2. اپنی Compose file میں موجود ہر image پر docker buildx imagetools inspect چلائیں اور تصدیق کریں کہ ہر image کے لیے linux/arm64 platform لائن موجود ہے۔
3. ARM instance پر apt update چلائیں اور اس سے ظاہر ہونے والی ہر Skipping acquire warning پڑھیں۔
4. ہر closed-source agent کے download page کو کھولیں جس پر آپ انحصار کرتے ہیں، اور نام کے ذریعے arm64 یا aarch64 build تلاش کریں۔
5. getconf PAGESIZE چلائیں اور memory کا سائز مقرر کرنے سے پہلے جواب نوٹ کریں۔
6. زیرِ غور ARM plan اور x86 plan، دونوں پر اپنا benchmark چلائیں۔

یہ پوسٹ کیا دعویٰ نہیں کرتی

ہم ARM اور x86 کے درمیان price to performance ratio فراہم نہیں کریں گے۔ ہر provider اور plan کے لحاظ سے فی core قیمت مختلف ہوتی ہے، اور کسی دوسرے کے hardware پر حاصل کیا گیا number آپ کے hardware کی کارکردگی کی پیش گوئی نہیں کرتا۔ اس کے بجائے خود پیمائش کریں۔ VPS کی benchmarking کے لیے ہماری گائیڈ میں sysbench اور fio کو ایسے طریقے کے ساتھ بیان کیا گیا ہے جسے آپ دوبارہ استعمال کر سکتے ہیں، جبکہ VPS کی اصل لاگت کیا ہوتی ہے تقابلی جائزے کے pricing والے پہلو کا احاطہ کرتی ہے۔ Storage، CPU architecture سے الگ فیصلہ ہے، اور VPS پر NVMe کا SATA SSD سے موازنہ اس پہلو کو بیان کرتا ہے۔ دونوں plans پر ایک ہی test چلائیں، اور جہاں ممکن ہو اپنا workload استعمال کریں۔ پھر اپنے numbers کی بنیاد پر فیصلہ کریں۔

FAQ

کیا میرے Docker containers ARM VPS پر چلیں گے؟

یہ اسی صورت چلیں گے جب stack کی ہر image کے manifest میں linux/arm64 entry موجود ہو۔ ہر image کو docker buildx imagetools inspect <image> کے ذریعے چیک کریں اور Platform: linux/arm64 لائن تلاش کریں۔ Docker Hub پر موجود official images عموماً multi-arch ہوتی ہیں۔ چھوٹے vendors کی images، اور وہ images جو آپ نے خود x86 machine پر build کی ہوں، اکثر multi-arch نہیں ہوتیں۔ اپنی images کے لیے docker buildx build --platform linux/amd64,linux/arm64 ... --push کے ساتھ دوبارہ build کریں، تاکہ ایک ہی tag دونوں architectures کے لیے کام کرے۔

ARM server پر exec format error کا کیا مطلب ہے؟

Kernel نے ایسی binary چلانے کی کوشش کی جس کے ELF header میں مختلف machine type درج تھا، اس لیے اس نے execution سے انکار کر دیا۔ arm64 host پر اس کا تقریباً ہمیشہ مطلب x86-64 binary یا container image ہوتا ہے۔ Docker پہلے warning دکھاتا ہے کہ requested image platform linux/amd64، detected host platform linux/arm64/v8 سے مطابقت نہیں رکھتا۔ حل یہ ہے کہ درست architecture کے لیے build تیار کی جائے۔ کوئی configuration change x86-64 binary کو ARM پر native طور پر نہیں چلا سکتی۔

کیا arm64 اور aarch64 ایک ہی چیز ہیں؟

ہاں۔ یہ دونوں 64-bit ARM instruction set کے نام ہیں۔ Kernel uname -m کے ذریعے aarch64 report کرتا ہے، جبکہ Debian اور Ubuntu packaging، اور Docker platform strings، arm64 استعمال کرتے ہیں۔ دوسری جانب بھی یہی تقسیم موجود ہے، جہاں uname -m، x86_64 کہتا ہے اور packaging amd64 کہتی ہے۔ اگر download page پر صرف aarch64 files دستیاب ہوں تو وہ اس machine کے لیے درست files ہیں جسے dpkg --print-architecture، arm64 کہتا ہے۔

کیا ARM VPS، x86 VPS سے زیادہ تیز ہوتا ہے؟

اس سوال کا کوئی عمومی جواب نہیں ہے، اور جو بھی واحد ratio آپ نے پڑھا ہے وہ ایسے hardware پر ناپا گیا تھا جو آپ کا hardware نہیں ہے۔ رفتار مخصوص CPU model، آپ کو دیے گئے cores کی تعداد، provider کی جانب سے tenants کے درمیان contention سنبھالنے کے طریقے، اور آپ کے workload کے vector instructions استعمال کرنے کی صلاحیت پر منحصر ہوتی ہے۔ جن دو plans میں آپ واقعی انتخاب کر رہے ہیں، ان کا benchmark کریں۔ اگر ممکن ہو تو اپنے workload کے ساتھ benchmark کریں، پھر ان numbers کا موازنہ کریں۔

Production server کو arm64 پر منتقل کرنے سے پہلے مجھے کیا چیک کرنا چاہیے؟

چار checks کریں، اسی ترتیب سے۔ تصدیق کریں کہ ہر container image میں arm64 manifest موجود ہے۔ تصدیق کریں کہ ہر third-party apt repository binary-arm64 publish کرتی ہے۔ تصدیق کریں کہ ہر closed-source agent کے لیے aarch64 download دستیاب ہے۔ اس کے بعد target instance پر getconf PAGESIZE چلائیں، کیونکہ 64 KiB page kernel بہت سی چھوٹی mappings والے processes کے memory footprint کو تبدیل کرتا ہے۔ جو چیز ان چار checks میں سے کسی ایک میں ناکام ہو، وہ اس مخصوص server کو x86 پر برقرار رکھنے کی وجہ ہے۔