Python და დემონები Vercel-ზე, MCP Fly-სა და Supabase-ში: როდის ჯობია ბექენდი საკუთარ სერვერზე

Vercel Ship-ის კონფერენციაზე 15 ოქტომბერს Vercel-მა გამოაცხადა, რომ Python მასთან საყოველთაოდ ხელმისაწვდომია, კონტეინერები ფუნქციებივით მუშაობს, ფონური ვორკერებისთვის კი დემონები გაჩნდა. იმავე კვირაში Fly.io-მ თავისი MCP-სერვერი აჩვენა, Supabase-მა კი მოყვა, როგორ მისცეთ თქვენს აპლიკაციას საკუთარი MCP-სერვერი. სიახლეებს საერთო აზრი აქვს: პლატფორმებს უნდათ, რომ მთელი ბექენდი მათთან ცხოვრობდეს და მას აგენტი მართავდეს. ბიზნესის მფლობელისთვის კითხვა სხვაა: სად იდგება სისტემა, რა ღირს თვეში და რა მოხდება, როცა ტარიფი შეიცვლება.

რა გამოაცხადეს

Vercel-მა 15 ოქტომბერს ბლოგში აღწერა ბექენდები Vercel-ზე: Python, კონტეინერები და დემონები. მათი ციფრებით, Python-ბექენდებს მათთან 150 000 გუნდი უშვებს, ხოლო კონტეინერების ბეტის დროს 5 000 გუნდმა 150 000 დეპლოი გააკეთა. კონტეინერები ფუნქციებივით მუშაობს Fluid compute-ზე Active CPU ტარიფით: ბაზის ან მოდელის პასუხის ლოდინში ფულს არ იხდით. მაგალითში კომპანია Delphi-მ Python-ბექენდი AWS ECS-დან გადმოიტანა: ათი ინჟინერი, ინფრასტრუქტურისთვის ცალკე ადამიანის გარეშე, და დღეში 100-ზე მეტი რელიზი.

იმავე დღეს Vercel-მა გამოაცხადა, რომ Python Vercel-ზე საყოველთაოდ ხელმისაწვდომია: პლატფორმა თავად ცნობს FastAPI-ს, Flask-სა და Django-ს, რიგებისთვის, საცავისა და მოდელებისთვის კი Python SDK-ს იძლევა. იქვე Vercel Daemons საჯარო ბეტაში გამოვიდა: კონტეინერები, რომლებიც მუდმივად მუშაობს და სამუშაოს თავად იღებს Vercel-ის რიგიდან, Celery-დან, BullMQ-დან, RabbitMQ-დან, Kafka-დან ან ბაზიდან.

21 ოქტომბერს Vercel-მა დაამატა მარშრუტიზაციის middleware Python-ზე: ის მთავარ აპლიკაციამდე სრულდება და შეუძლია მოთხოვნა გადაწეროს ან გადაამისამართოს. 23 ოქტომბერს კი CLI-ში ხარჯების მართვა გაჩნდა: ბრძანება vercel budgets ხარჯებსა და ბიუჯეტს აჩვენებს, ფლაგი --pause კი ყველა პროექტის production-დეპლოებს აჩერებს, როცა ხარჯი 100 %-ს მიაღწევს.

Fly.io-მ 23 ოქტომბერს წარადგინა Fly MCP Server: ერთი MCP-სერვერი, რომლის გავლითაც აგენტი მუშაობს როგორც Sprites-ის სენდბოქსებთან, ისე სამუშაო Fly Machines-თან. Sprite არის Linux-მანქანა საკუთარი დისკით, და Machine-ზე გადატანა ისე გამოიყურება, როგორც Linux-სერვისის გადატანა ორ Linux-მანქანას შორის. ჩანაწერში არის ციფრი Databricks-ის ანგარიშიდან Neon-ის ტელემეტრიაზე: 2023 წლის ოქტომბერში ბაზების 0,1 %-ს აგენტები ქმნიდნენ, 2025 წლის ოქტომბერში უკვე 80 %-ს.

Supabase-მა 22 ოქტომბერს აჩვენა, როგორ მისცეთ აპლიკაციას საკუთარი MCP-სერვერი. თქვენი აპლიკაციის კლიენტი ChatGPT-დან ან Claude-დან საკუთარი ანგარიშით შედის, ინსტრუმენტის ყოველი გამოძახება მისი სახელით სრულდება, და Postgres-ში RLS-პოლიტიკები წყვეტს, რისი უფლება აქვს. ეს ნაწილი მომწონს: უფლებები იგივეა, რაც აპლიკაციაში, და სერვისული გასაღები არ სჭირდება.

მაგალითი: წარმოება და ანგარიში თვის ბოლოს

საწარმოო კომპანია შეკვეთებს ითვლის: პროგრამა კონსტრუქტორული დოკუმენტაციის ქსელურ საქაღალდეებს SMB-ით, VPN-ის გავლით კითხულობს, მასალებს 1C-ის ნომენკლატურას ადარებს და ფაილებს ლაზერისთვის სახელს უცვლის. აღწერილი პლატფორმებიდან ვერცერთი ამას ვერ გააკეთებს: ბექენდი კომპანიის ქსელის შიგნით უნდა იდგეს.

ბიუჯეტი პაუზით სასარგებლო ღილაკია, მაგრამ ნახეთ, რას აკეთებს: 100 %-ზე production-დეპლოები ჩერდება. სერვისული კომპანიისთვის ეს ნიშნავს, რომ საიტი განაცხადების ფორმით იმ დღეს გაჩერდება, როცა რეკლამამ ჩვეულებრივზე მეტი ხალხი მოიყვანა. საკუთარ სერვერზე ანგარიში ნებისმიერ თვეში ერთნაირია, დატვირთვის ნახტომს კი ლოგებში დაინახავთ.

როგორ არის ეს ჩემთან მოწყობილი

საიტი kononov.dev და შიდა სერვისი „ყავა ერთად“ ერთ სერვერზე დგას 2 GB მეხსიერებით, Docker-ში, Nginx-ის უკან. კონტეინერებს მეხსიერების მკაცრი ლიმიტები აქვს, განახლებისას ძველი ინსტანსი ახლის გაშვებამდე ჩერდება, ხოლო თუ აწყობას მეხსიერება არ ჰყოფნის, იმიჯს სერვერის გარეთ ვაწყობ და მზას ვტვირთავ. ამასთან „ყავა ერთად“ Cloudflare Workers-ის runtime-ისთვის არის დაწერილი, D1 API-ით ლოკალური SQLite-ის თავზე Docker volume-ში: პლატფორმის runtime საკუთარ აპარატურაზე და უფასო ინსტრუმენტებზე.

სამხრეთ აფრიკაში მანქანების გაქირავების კომპანიას საკუთარი სერვერის დაყენება შევთავაზე, რადგან ჯავშნისა და გაცემის ლოგიკა AmoCRM-ის პარამეტრებს გადაიზარდა. იდეას მხარი დაუჭირეს, და 2025 წლის განმავლობაში სისტემა ინტეგრაციებიდან გაიზარდა საიტამდე ჯავშნის სრული ციკლით, მენეჯერების აპლიკაციამდე და დოკუმენტების ჯაჭვამდე. ყველა შემთხვევაში კოდი, ბაზა, სერვერი და წვდომები დამკვეთს ეკუთვნის.

პლატფორმა ყოველი ცვლილების პრევიუს და ერთი ღილაკით დაბრუნებას იძლევა, შტატში ადმინისტრატორის გარეშე. ათინჟინრიან გუნდს, რომელსაც დღეში ასი რელიზი აქვს, როგორც Delphi-ს, ეს ამართლებს. Vercel Daemons, Fly MCP და Supabase-ის MCP-ბლოკი ჩემთან არ გამიშვია და მათი აღწერებით ვმსჯელობ.

რას გავაკეთებდი

დაითვალეთ მომავალი ერთი წლის ხარჯი: პლატფორმის ტარიფი, Active CPU და დემონები შეადარეთ სერვერის ქირასა და მის მომსახურებაზე დახარჯულ საათებს. ერთჯერადი დახვეწა ჩემთან საათში დაახლოებით $80 ღირს, მხარდაჭერა ცალკე შეთანხმებით ფორმდება, და სერვერზე დახარჯული საათები ამ გაანგარიშებაში პატიოსნად უნდა ჩაითვალოს.

ჩამოწერეთ, რა სჭირდება ბექენდს იმისგან, რასაც პლატფორმა არ იძლევა: VPN ლოკალურ ქსელში, SMB, ტელეფონია, ხანგრძლივი პროცესები მდგომარეობით.

Dockerfile პლატფორმისთვის და საკუთარი სერვერისთვის ერთნაირი იყოს.

MCP-წვდომა საკუთარ აპლიკაციაზე Supabase-ის სქემით გააკეთეთ: გამოძახებები მომხმარებლის სახელით და უფლებების იგივე შემოწმებები, რაც აპლიკაციაში. 2023 წელს ლონდონის საკონსულტაციო კომპანიისთვის მოდელის მიერ ფუნქციების გამოძახებით ვექსპერიმენტობდი; დღეს იმას, რაც მაშინ გამოვიდა, MCP-სერვერის პროტოტიპს დავარქმევდი.

სისტემის ცენტრზე, რომელიც მდგომარეობას ინახავს და პროცესს ასრულებს, არის სტატია სერვერზე, როგორც სისტემის ბირთვზე. ამ მიმოხილვის პროექტები: „ყავა ერთად“ და გაქირავება სამხრეთ აფრიკაში. ვის ეკუთვნის კოდი და სერვერი, ვარჩევ მიმოხილვაში ციფრული სუვერენიტეტი მარტივად, Docker Compose Kubernetes-ის წინააღმდეგ აქ, რეალური დრო მიმოხილვაში WebSocket-ზე, სქემის მიგრაციები მიმოხილვაში Supabase-ის ბრენჩებსა და D1-ზე. მძიმე ანგარიში და სამუშაო ბაზა ადრე გავმიჯნე. მიმართულებები: ინფრასტრუქტურა და DevOps და აპლიკაცია თქვენი სცენარისთვის. თუ ირჩევთ, სად იცხოვრებს ბექენდი, მომწერეთ, რა უნდა აკეთოს, და გეტყვით, რას ავირჩევდი თავად. ამოცანის განხილვა.