Memilih Hosting dan Server untuk Aplikasi Next.js

Memilih Hosting dan Server untuk Aplikasi Next.js

• 1. Pendahuluan
• 2. Memahami Model Rendering di Next.js
• 3. Daftar dan Perbandingan Hosting untuk Next.js
• 4. Peran CDN dalam Arsitektur Web Modern
• 5. Express.js dan Alasan Menggunakan Custom Server
• 6. Alternatif Modern untuk Express.js
• 7. Strategi Memilih Hosting dan Server-Side Framework
• 8. Kesimpulan
• 📚 Referensi

1. Pendahuluan

Dalam beberapa tahun terakhir, Next.js telah berkembang menjadi salah satu framework paling populer untuk membangun aplikasi web modern berbasis React. Dikenal karena fleksibilitasnya dalam mendukung berbagai metode rendering—seperti Static Site Generation (SSG), Server-side Rendering (SSR), Incremental Static Regeneration (ISR), dan Client-side Rendering (CSR)—Next.js menawarkan fondasi kuat untuk membangun aplikasi yang cepat, dinamis, dan mudah dikembangkan.

Namun, seiring dengan bertambahnya fitur dan fleksibilitas tersebut, kebutuhan akan strategi hosting dan server yang tepat juga menjadi semakin penting. Tidak semua penyedia layanan hosting memberikan dukungan yang optimal untuk seluruh fitur Next.js, terutama ketika proyek melibatkan API kompleks, middleware kustom, atau integrasi backend berbasis server. Sementara layanan seperti Vercel menawarkan kemudahan dan integrasi mendalam, proyek tertentu mungkin memerlukan kontrol lebih besar yang hanya dapat dicapai melalui penggunaan custom server atau framework backend tambahan seperti Express.js, Fastify, atau NestJS.

Artikel ini bertujuan untuk membantu developer dalam memahami perbedaan utama antara berbagai solusi hosting yang tersedia, serta kapan dan mengapa perlu mempertimbangkan penggunaan custom server dalam konteks aplikasi Next.js. Dengan membahas karakteristik penyedia hosting populer, konsep CDN, serta perbandingan berbagai framework server-side modern, artikel ini memberikan panduan teknis menyeluruh untuk menyusun arsitektur deployment yang efisien, scalable, dan sesuai kebutuhan aplikasi Anda.

2. Memahami Model Rendering di Next.js

Salah satu kekuatan utama Next.js terletak pada fleksibilitasnya dalam menangani berbagai model rendering. Memahami perbedaan antara metode-metode ini sangat penting, karena masing-masing memiliki implikasi langsung terhadap pemilihan hosting, performa aplikasi, serta skema deployment.

• 🔹 Static Site Generation (SSG)

SSG adalah metode di mana halaman-halaman HTML dirender sepenuhnya pada saat proses build, lalu disimpan sebagai file statis. Halaman hasil SSG disajikan melalui CDN, memberikan waktu muat yang sangat cepat dengan beban server yang minimal.

Cocok untuk: Konten statis, blog, landing page Dukungan hosting: GitHub Pages, Vercel, Netlify, dan semua static hosting

• 🔹 Server-side Rendering (SSR)

SSR merender halaman secara dinamis di server pada setiap permintaan. Ini memberikan fleksibilitas tinggi, terutama saat data yang dibutuhkan selalu berubah atau bergantung pada request tertentu.

Cocok untuk: Dashboard pengguna, aplikasi yang memerlukan autentikasi, atau data yang selalu real-time Dukungan hosting: Vercel (dengan serverless functions), Railway, Fly.io, Render, VPS

• 🔹 Incremental Static Regeneration (ISR)

ISR adalah pendekatan hybrid antara SSG dan SSR. Halaman tetap disajikan dari CDN, tetapi dapat diregenerasi secara asinkron di background berdasarkan waktu atau permintaan tertentu, tanpa perlu build ulang seluruh aplikasi.

Cocok untuk: Konten semi-dinamis (misal: daftar produk, artikel) Dukungan hosting: Vercel (native), Netlify (dengan beberapa keterbatasan)

• 🔹 Client-side Rendering (CSR)

CSR berarti konten dinamis hanya dirender di sisi klien setelah halaman dimuat. Ini dilakukan melalui React biasa di dalam komponen Next.js. CSR sering digunakan bersama metode lainnya untuk meningkatkan performa dan interaktivitas.

Cocok untuk: Interaksi dinamis pasca-load, aplikasi SPA-style Tidak bergantung pada jenis hosting tertentu

• 🔄 Pengaruh Model Rendering terhadap Hosting

Pemilihan metode rendering menentukan kapabilitas yang dibutuhkan dari layanan hosting. Misalnya:

• Jika proyek hanya menggunakan SSG dan CSR, maka static hosting seperti GitHub Pages atau Netlify sudah memadai.
• Jika menggunakan SSR atau API Routes, maka dibutuhkan hosting yang mendukung fungsi server-side (seperti Vercel dengan Serverless Functions, atau Railway dengan custom server).
• Jika membutuhkan middleware, pengelolaan sesi yang kompleks, atau protokol backend lainnya, maka Anda akan memerlukan custom server, yang tidak bisa dijalankan di lingkungan serverless seperti Vercel.

3. Daftar dan Perbandingan Hosting untuk Next.js

Ekosistem Next.js sangat fleksibel, sehingga dapat dijalankan di berbagai jenis platform hosting — dari layanan yang menawarkan dukungan native, hingga opsi custom server di VPS atau cloud platform. Pemilihan platform hosting sangat dipengaruhi oleh metode rendering yang digunakan, kebutuhan backend, dan arsitektur proyek secara keseluruhan.

Berikut ini klasifikasi hosting berdasarkan kemampuannya dalam mendukung fitur-fitur Next.js.

🔹 1. Hosting dengan Native Support

Platform yang dirancang secara khusus untuk menjalankan aplikasi Next.js dengan dukungan penuh terhadap fitur-fitur seperti SSR, ISR, dan fungsi API bawaan.

• ✅ Vercel

• Dibuat oleh tim yang sama dengan pengembang Next.js.
• Mendukung semua fitur Next.js (SSG, SSR, ISR, Middleware, Edge Functions).
• Deployment otomatis dari Git.
• Tidak mendukung custom server seperti Express.js.

• ✅ Netlify

• Mendukung Next.js melalui build adapter (@netlify/next).
• Dukungan untuk SSG, sebagian SSR/ISR melalui Netlify Functions.
• Tidak mendukung server custom (Express) secara native.

🔹 2. Hosting yang Mendukung Custom Server

Platform yang memungkinkan Anda menjalankan server Node.js penuh, termasuk penggunaan Express.js, Fastify, dan framework lain.

• ✅ Railway

• Mendukung custom server (Express.js, Fastify, dsb).
• Deployment mudah dengan Git integration.
• Cocok untuk monolitik frontend + backend.
• Free tier tersedia.

• ✅ Render

• Serupa dengan Railway, dengan kontrol lebih granular pada service.
• Mendukung web service, background jobs, cron jobs.
• Mendukung custom domain dan autoscaling terbatas.

• ✅ Fly.io

• Dirancang untuk deployment global (Edge-like).
• Mendukung aplikasi berbasis Docker, termasuk server Next.js + Express.
• Cocok untuk developer yang membutuhkan performa tinggi dan geolokasi.

🔹 3. Hosting Static-only

Hosting jenis ini hanya mendukung aplikasi Next.js yang telah di-export secara statik (next export), tanpa dukungan SSR, API routes, atau middleware.

• ✅ GitHub Pages

• Hanya bisa digunakan jika seluruh halaman dirender secara statik.
• Tidak mendukung API Routes maupun SSR.
• Cocok untuk landing page atau dokumentasi.

🔹 4. Hosting Cloud/VPS Fleksibel

Platform ini menawarkan infrastruktur mentah di mana Anda bisa mengatur semuanya sendiri, termasuk Node.js, server backend, dan layanan pendukung lainnya.

• ✅ DigitalOcean (App Platform atau Droplet)

• Bisa digunakan untuk menjalankan Next.js + Express secara penuh.
• App Platform menyederhanakan proses deployment, mirip dengan Heroku.

• ✅ AWS (EC2, Lambda, Amplify)

• Paling fleksibel dan powerful, namun konfigurasi lebih kompleks.
• Lambda bisa digunakan untuk serverless, EC2 untuk custom server.
• CloudFront dapat digunakan sebagai CDN.

• ✅ Google Cloud / Azure

• Sama fleksibelnya dengan AWS, dengan tooling dan dashboard yang berbeda.
• Cocok untuk enterprise dan integrasi sistem skala besar.

📊 Tabel Perbandingan Hosting

📌 Catatan Penting:

• CDN penting untuk distribusi konten statis dan hasil SSG/ISR.
• Custom server dibutuhkan jika menggunakan Express.js, WebSocket, atau logika backend kustom.
• Serverless platform (seperti Vercel) sangat baik untuk frontend murni atau aplikasi dengan kebutuhan backend ringan.

4. Peran CDN dalam Arsitektur Web Modern

Dalam pengembangan web modern, terutama untuk aplikasi yang melayani pengguna lintas geografis, Content Delivery Network (CDN) menjadi salah satu komponen arsitektur yang krusial. CDN membantu meningkatkan kecepatan akses, mengurangi beban server utama, dan meningkatkan skalabilitas sistem secara keseluruhan.

🔹 Apa Itu CDN dan Bagaimana Cara Kerjanya?

CDN adalah jaringan global server proxy (disebut juga edge nodes) yang menyimpan salinan konten dari server utama (origin server) dan menyajikannya kepada pengguna berdasarkan lokasi geografis mereka. Ketika pengguna mengakses sebuah halaman, permintaan mereka diarahkan ke edge node terdekat secara geografis, bukan langsung ke server pusat. Ini mengurangi latensi dan mempercepat waktu muat halaman.

Contoh alur sederhana:

1. Pengguna mengakses halaman web.
2. DNS mengarahkan ke edge node CDN terdekat.
3. Jika konten tersedia di cache CDN (cache hit), konten langsung dikirim ke pengguna.
4. Jika tidak tersedia (cache miss), edge node mengambil konten dari origin server, menyimpannya, dan mengirimkannya ke pengguna.

🔹 Mengapa CDN Penting dalam Performa Next.js?

Next.js menghasilkan berbagai jenis konten, mulai dari halaman statik (SSG), konten dinamis (SSR), hingga kombinasi keduanya (ISR). Tanpa CDN, semua permintaan — termasuk konten statik — harus dilayani langsung dari server utama, yang dapat menyebabkan bottleneck dan latensi tinggi terutama bagi pengguna di lokasi jauh dari server tersebut.

CDN memberikan keuntungan signifikan dalam konteks Next.js:

• Distribusi global konten SSG dan ISR
• Pengurangan beban server untuk permintaan berulang
• Peningkatan Time to First Byte (TTFB) dan Core Web Vitals
• Pemrosesan edge untuk middleware atau logic ringan (Edge Functions)

🔹 Integrasi Otomatis CDN di Platform Hosting

Beberapa platform hosting Next.js menyediakan integrasi CDN secara default, tanpa konfigurasi tambahan:

• Vercel Otomatis mendistribusikan halaman hasil SSG dan ISR melalui jaringan edge mereka. Middleware dan Edge Functions dijalankan pada edge node secara global. Halaman SSR juga di-cache secara cerdas jika memungkinkan.

• Netlify Menggunakan Netlify Edge untuk mendistribusikan konten statik dan mendukung fungsi serverless secara geografis. Dukungan untuk Next.js dioptimalkan melalui plugin resmi.

• GitHub Pages Menyajikan file statik melalui jaringan CDN GitHub, meskipun tidak mendukung SSR atau API routes.

• Fly.io Memberikan arsitektur edge-native, memungkinkan Anda menjalankan aplikasi Next.js (termasuk server custom) di wilayah geografis tertentu secara global.

🔹 Cache Statis vs Cache Dinamis (ISR)

Salah satu fitur unggulan Next.js adalah Incremental Static Regeneration (ISR), yang memungkinkan konten statik diperbarui secara dinamis berdasarkan waktu tertentu atau permintaan pengguna. CDN memainkan peran penting dalam strategi ini.

Contoh penerapan:

• Halaman produk e-commerce dengan informasi harga yang berubah setiap beberapa menit dapat menggunakan ISR untuk keseimbangan antara performa dan aktualisasi data.

5. Express.js dan Alasan Menggunakan Custom Server

🔹 Apa Itu Custom Server di Next.js?

Secara default, aplikasi Next.js dijalankan menggunakan server internal yang menangani routing, rendering, dan API routes. Namun, dalam beberapa kasus, developer mungkin membutuhkan fleksibilitas lebih untuk menangani permintaan HTTP secara manual—di sinilah konsep custom server digunakan.

Custom server memungkinkan Anda membungkus aplikasi Next.js di dalam server Node.js yang dikontrol penuh, menggunakan framework seperti Express.js, Fastify, atau framework lainnya. Hal ini memberi Anda akses langsung ke objek req dan res, serta kebebasan penuh dalam menangani request, middleware, dan routing.

🔹 Mengapa Next.js Tidak Memerlukan Express.js Secara Default?

Next.js sudah menyediakan:

• Routing otomatis melalui folder pages/
• API routes (pages/api/) untuk backend ringan
• Middleware berbasis edge (middleware.ts)
• Dukungan serverless pada platform seperti Vercel dan Netlify

Dengan fitur ini, kebanyakan aplikasi web modern tidak membutuhkan Express.js, terutama jika menggunakan metode deployment serverless.

🔹 Kapan dan Mengapa Express.js Dibutuhkan?

Namun, ada kasus-kasus tertentu di mana penggunaan Express.js atau custom server menjadi relevan dan bahkan penting:

1. Middleware kompleks

   • Validasi request tingkat lanjut
   • Custom logging, rate-limiting, atau pengelolaan header yang lebih detail

2. Autentikasi berbasis sesi atau cookie

   • Integrasi dengan express-session, Passport.js, atau strategi login lain di luar kemampuan bawaan Next.js

3. Integrasi layanan eksternal

   • Webhook handling (dengan request parsing kustom)
   • API proxy dengan kontrol penuh

4. Routing kustom

   • Subdomain, multi-tenant architecture
   • Routing versi API (/api/v1, /api/v2, dll)

5. Kontrol penuh atas server

   • Dibutuhkan saat aplikasi dijalankan di lingkungan yang tidak mendukung serverless atau saat menggunakan protokol tambahan (seperti WebSocket)

🔹 Kapan Tidak Perlu Menggunakan Custom Server?

Tidak disarankan menggunakan custom server jika:

• Aplikasi hanya menggunakan SSG, SSR, atau ISR
• API cukup ditangani melalui pages/api/
• Hosting dilakukan di Vercel atau Netlify
• Tidak membutuhkan sesi persisten atau middleware kustom tingkat lanjut

Penggunaan custom server juga menonaktifkan optimasi bawaan Next.js, seperti automatic static optimization, sehingga perlu dipertimbangkan secara matang.

🔹 Studi Kasus: Express untuk Middleware dan Autentikasi

Berikut adalah contoh implementasi sederhana Next.js dengan Express untuk menangani autentikasi cookie dan route API kustom:

// server.js
const express = require('express');
const next = require('next');
const cookieParser = require('cookie-parser');

const dev = process.env.NODE_ENV !== 'production';
const app = next({ dev });
const handle = app.getRequestHandler();

app.prepare().then(() => {
  const server = express();

  server.use(cookieParser());

  server.use((req, res, next) => {
    if (req.path.startsWith('/admin') && !req.cookies.token) {
      return res.redirect('/login');
    }
    next();
  });

  server.all('*', (req, res) => handle(req, res));

  server.listen(3000, () => {
    console.log('> Ready on http://localhost:3000');
  });
});

6. Alternatif Modern untuk Express.js

Meskipun Express.js masih populer, banyak framework modern bermunculan yang menawarkan performa lebih tinggi, dukungan TypeScript lebih baik, serta arsitektur yang lebih modular. Berikut beberapa alternatif yang layak dipertimbangkan:

🔹 Fastify

Framework minimalis yang difokuskan pada performa tinggi dan efisiensi penggunaan memori.

Kelebihan:

• Lebih cepat daripada Express dalam benchmark real-world
• Dukungan bawaan untuk schema validation (JSON Schema)
• Plugin system yang ekstensibel
• Dukungan TypeScript sangat baik

Cocok untuk: REST API cepat, backend modular, proyek skala menengah hingga besar

🔗 https://www.fastify.io/

🔹 Koa

Dibuat oleh tim yang sama dengan Express, namun didesain ulang dengan pendekatan async/await dan lebih minimalis.

Kelebihan:

• Middleware berbasis async/await
• Tidak membawa middleware bawaan — fleksibel dan bersih
• Sangat cocok untuk arsitektur yang dikendalikan developer sepenuhnya

Cocok untuk: Developer yang menginginkan kontrol penuh dan modularitas tinggi

🔗 https://koajs.com/

🔹 NestJS

Framework progresif dan opiniatif yang dibangun di atas Express (atau Fastify) dengan dukungan penuh untuk TypeScript dan arsitektur berbasis module dan decorator.

Kelebihan:

• Arsitektur mirip Angular (module, service, controller)
• Cocok untuk aplikasi skala besar dan enterprise
• Dukungan lengkap untuk WebSocket, GraphQL, microservices

Cocok untuk: Aplikasi kompleks, tim besar, arsitektur enterprise

🔗 https://nestjs.com/

🔹 Hono

Framework super-ringan yang kompatibel dengan runtime modern seperti Cloudflare Workers, Deno, Bun, dan juga Node.js.

Kelebihan:

• Sangat cepat dan kecil (LT 20kB)
• API mirip Express, tapi lebih modern
• Cocok untuk edge functions dan serverless environments

Cocok untuk: Aplikasi ringan, edge-first, serverless

🔗 https://hono.dev/

🔹 uWebSockets.js

Framework yang difokuskan pada performa tinggi, khususnya untuk aplikasi real-time dan koneksi persistent seperti WebSocket.

Kelebihan:

• Benchmark performa tertinggi di antara framework Node.js
• Ideal untuk aplikasi dengan kebutuhan latensi sangat rendah

Kekurangan:

• API lebih kompleks dan low-level
• Dokumentasi dan ekosistem terbatas dibanding Express/Fastify

Cocok untuk: Aplikasi real-time, sistem trading, dashboard monitoring

🔗 https://github.com/uNetworking/uWebSockets.js/

📊 Perbandingan Ringkas

Dengan memilih framework yang tepat, Anda dapat merancang backend yang lebih sesuai dengan kebutuhan aplikasi — baik dari sisi performa, skala, maupun kompleksitas arsitektur.

7. Strategi Memilih Hosting dan Server-Side Framework

Pemilihan platform hosting dan framework server-side tidak bisa dipisahkan dari kebutuhan teknis dan kompleksitas aplikasi. Masing-masing solusi memiliki kelebihan dan keterbatasan yang perlu dipertimbangkan secara menyeluruh sejak tahap perencanaan.

Berikut adalah strategi praktis berdasarkan kompleksitas aplikasi dan tingkat kontrol yang diinginkan:

✅ 1. Aplikasi dengan SSG/SSR Ringan → Gunakan Vercel

Untuk aplikasi yang menggunakan:

• Halaman statis (getStaticProps)
• Server-side rendering ringan (getServerSideProps)
• API routes sederhana
• Middleware dasar (middleware.ts)
• Tidak memerlukan server persistent atau koneksi langsung ke database

Rekomendasi: Gunakan Vercel, karena:

• Integrasi langsung dengan Next.js
• Dukungan native untuk SSG, SSR, ISR, dan Edge Middleware
• CDN global tanpa konfigurasi tambahan
• CI/CD otomatis dari GitHub/GitLab

Cocok untuk: Blog, landing page, dashboard ringan, portal konten

✅ 2. Aplikasi dengan Backend Kompleks → Gunakan Railway, Fly.io + Fastify/NestJS

Untuk aplikasi yang membutuhkan:

• Autentikasi berbasis sesi
• Middleware atau routing kompleks
• REST API kustom atau versi API
• Integrasi database atau third-party service
• Webhook handler atau pemrosesan data tingkat lanjut

Rekomendasi:

• Gunakan hosting seperti Railway, Render, atau Fly.io

• Jalankan custom server menggunakan framework modern:

  • Fastify untuk API ringan dan performa tinggi
  • NestJS untuk aplikasi enterprise dan skala besar

Arsitektur Umum:

• Next.js tetap digunakan untuk frontend
• Custom server menangani API, autentikasi, middleware, dsb
• Pilihan untuk digabung dalam satu monolit atau dipisah (frontend/backend)

Cocok untuk: SaaS, admin dashboard, aplikasi dengan otorisasi kompleks

✅ 3. Ingin Fleksibilitas Penuh → Gunakan VPS atau Cloud Platform

Jika Anda membutuhkan:

• Kontrol penuh terhadap environment server
• Arsitektur multi-layanan (microservices)
• Kebutuhan protokol non-HTTP (misalnya WebSocket, TCP, atau custom port)
• Konfigurasi tingkat lanjut seperti reverse proxy, load balancing, custom domain routing

Rekomendasi:

• Gunakan VPS (misalnya DigitalOcean, Hetzner) atau cloud seperti AWS EC2, GCP Compute Engine
• Jalankan backend dengan framework pilihan (Express, Fastify, NestJS, dsb)
• Kelola deployment dengan Docker, PM2, atau container orchestration seperti Docker Compose

Keuntungan:

• Fleksibilitas maksimal, tidak bergantung pada batasan platform
• Dapat dikombinasikan dengan CDN eksternal (Cloudflare, CloudFront) jika dibutuhkan

Cocok untuk: Aplikasi skala besar, proyek dengan arsitektur khusus, sistem multi-tenant

🧠 Rekomendasi Kombinasi Hosting + Framework Berdasarkan Skala dan Kebutuhan

📌 Penutup Strategi

Dalam memilih hosting dan framework server-side untuk Next.js, tidak ada satu solusi tunggal yang cocok untuk semua proyek. Evaluasi harus dilakukan berdasarkan:

• Kompleksitas aplikasi
• Kebutuhan integrasi backend
• Skala pengguna dan lokasi geografis
• Preferensi arsitektur dan tim pengembang

Mulailah dari solusi sederhana seperti Vercel, lalu beralih ke arsitektur custom bila kebutuhan semakin kompleks. Pendekatan bertahap ini memungkinkan pengembangan yang efisien dan scalable seiring pertumbuhan aplikasi.

8. Kesimpulan

Pemilihan hosting dan server-side framework untuk aplikasi Next.js bukanlah keputusan yang bersifat universal. Setiap proyek memiliki kebutuhan unik yang bergantung pada fitur yang digunakan, skala trafik, arsitektur backend, serta tingkat kontrol yang diinginkan atas lingkungan server.

Meskipun platform seperti Vercel menawarkan integrasi native dan efisiensi tinggi untuk sebagian besar use case Next.js—terutama yang bersifat statik atau ringan—ada banyak situasi di mana solusi tersebut tidak mencukupi. Kebutuhan akan middleware kompleks, autentikasi berbasis sesi, integrasi backend lanjutan, atau komunikasi real-time adalah beberapa alasan utama mengapa pendekatan custom server menjadi relevan.

Framework seperti Fastify dan Hono muncul sebagai alternatif modern dari Express.js, menawarkan performa yang lebih tinggi, dukungan TypeScript yang lebih kuat, serta arsitektur yang lebih modular atau ringan. Untuk proyek berskala besar, NestJS juga memberikan pendekatan yang terstruktur dan cocok untuk tim dengan kebutuhan enterprise.

Fokus utama dalam menentukan arsitektur bukan hanya soal mengikuti tren, tetapi pada:

• Efisiensi pengembangan dan pemeliharaan
• Performa aplikasi secara real-world
• Kemudahan deployment dan scaling

Dengan mempertimbangkan berbagai faktor tersebut secara cermat, Anda dapat memilih kombinasi hosting dan framework yang benar-benar sesuai dengan kebutuhan teknis dan roadmap proyek Anda.

📚 Referensi

Berikut adalah referensi teknis dan dokumentasi resmi yang digunakan untuk menyusun artikel ini:

1. Next.js Documentation https://nextjs.org/docs

2. Vercel Documentation https://vercel.com/docs

3. Netlify Next.js Support https://docs.netlify.com/integrations/frameworks/next-js/overview/

4. Fastify Documentation https://www.fastify.io/docs/latest/

5. NestJS Documentation https://docs.nestjs.com/

6. Koa Documentation https://koajs.com/

7. Hono Documentation https://hono.dev/

8. uWebSockets.js GitHub https://github.com/uNetworking/uWebSockets.js/

9. Railway Docs https://docs.railway.app/

10. Fly.io Docs https://fly.io/docs/

11. Render Docs https://render.com/docs

12. Cloudflare CDN Guide https://www.cloudflare.com/learning/cdn/what-is-a-cdn/

13. DigitalOcean App Platform https://www.digitalocean.com/products/app-platform/