এই বিভাগে আগে কভার করা Cloud আর managed প্ল্যাটফর্ম সাধারণত ম্যানুয়াল ফাইল আপলোডকে আরও স্বয়ংক্রিয় কিছু দিয়ে প্রতিস্থাপন করে: একবার একটি Git repository সংযুক্ত করুন, আর এতে প্রতিটি push স্বয়ংক্রিয়ভাবে deploy হয়, কোনো FTP client আর কোনো ম্যানুয়াল ফাইল স্থানান্তর একেবারেই জড়িত না থাকে।
আপনি একবার, এর dashboard-এর মাধ্যমে, আপনার GitHub (বা একই ধরনের) repository হোস্টিং প্ল্যাটফর্মের সাথে সংযুক্ত করেন। তখন থেকে, প্যাটার্নটি সহজভাবে: স্থানীয়ভাবে কোড লিখুন, এটি commit করুন, repository-তে push করুন — আর প্ল্যাটফর্মটি push সনাক্ত করে, একটি build ধাপ দরকার হলে প্রোজেক্ট build করে, আর ফলাফল স্বয়ংক্রিয়ভাবে deploy করে, সাধারণত এক বা দুই মিনিটের মধ্যে।
যে প্রোজেক্টের একটি দরকার — সবচেয়ে উল্লেখযোগ্যভাবে একটি React অ্যাপ — এর জন্য, প্ল্যাটফর্মটি deployment-এর অংশ হিসেবে স্বয়ংক্রিয়ভাবে প্রোজেক্টের build ধাপ চালায় (সোর্স কোডকে static-হোস্টিং পাঠে কভার করা static ফাইলে পরিণত করা), আপনি স্থানীয়ভাবে এটি চালিয়ে হাতে output আপলোড করার বদলে। এটি ঠিক deploying-a-react-app পাঠের workflow, শীঘ্রই সম্পূর্ণভাবে বর্ণিত।
এই সাইট নিজেই ঠিক এভাবে deploy হয় — এর repository-তে একটি push একটি স্বয়ংক্রিয় build চালু করে আর, প্রোজেক্টের টেকনিক্যাল ডকুমেন্টেশনে বর্ণিত এর নিজস্ব স্থাপত্য অনুযায়ী, কেউ ম্যানুয়ালি একটি সার্ভার স্পর্শ না করেই আপডেট করা পাতা প্রকাশ করে।
বেশিরভাগ প্ল্যাটফর্ম ডিফল্টভাবে একটি নির্দিষ্ট branch-এ (সাধারণত main) প্রতিটি push-এ স্বয়ংক্রিয়ভাবে deploy করে — বাস্তবে এটিই "continuous deployment" বোঝায়। কিছু সেটআপ এর বদলে একটি build-কে live সাইটে উন্নীত করতে একটি ম্যানুয়াল ক্লিক দাবি করে, যা কিছু লাইভ হওয়ার আগে একটি অতিরিক্ত ইচ্ছাকৃত চেকপয়েন্টের বিনিময়ে সামান্য গতি বিনিময় করে — এমন একটি প্রোজেক্টের জন্য একটি যুক্তিসঙ্গত পছন্দ যেখানে একটি দুর্ঘটনাজনিত push সাথে সাথে প্রকাশ্য হওয়া উচিত নয়।
Git-ভিত্তিক deployment বিশেষভাবে cloud/managed প্ল্যাটফর্ম আর React/Node.js প্রোজেক্টের জন্য ডিফল্ট আর প্রত্যাশিত workflow। PHP বা WordPress-এর জন্য shared হোস্টিংও কখনো কখনো এর জন্য কনফিগার করা যায়, কিন্তু আগের দুই পাঠে কভার করা FTP/SFTP আর control-panel-ভিত্তিক deployment বাস্তবে সেখানে অনেক বেশি সাধারণ থেকে যায়।