5 Beste Alternativen zu Scalingo

DigitalOcean funktioniert gut für ein Produktteam von 2 bis 5 Personen, das jetzt etwas im PaaS-Stil möchte, aber später nicht nur auf PaaS-Primitiven festgelegt sein will. Mein typisches Muster ist: App Platform Web Service für die API, eine Worker-Komponente für Queues und eine kostenlose statische Site-Komponente für Docs/Marketing; jede Komponente kann unabhängig skaliert werden, ab 5 $/Monat für einen kleinen Container. Wenn ich eine stabile Ausgangsidentität für Zulassungslisten von Drittanbietern brauche, kann ich das Add-on für dedizierte Egress-IP (25 $/app) hinzufügen, anstatt eine eigene NAT-Schicht aufzubauen. Wenn ich anfangs kostenempfindlich bin, ist die Gratisstufe für bis zu drei statische Sites ein praktischer Ort, um eine Statusseite oder öffentliche Dokumentation zu parken. Später kann ich Performance-Hotspots auf Droplets oder Kubernetes verschieben, ohne Cloud-Anbieter oder Abrechnungskonten zu wechseln.

Scalingo wirkt Heroku-ähnlich: Ich kann über Buildpacks deployen (einschließlich benutzerdefinierter Buildpacks), Review Apps für jeden GitHub/GitLab-PR erhalten und verwaltete PostgreSQL/MySQL/Redis/MongoDB/OpenSearch/InfluxDB vom selben Dashboard hinzufügen. Es hat auch einen Autoscaler, der kostenlos konfiguriert werden kann, aber für alle zusätzlichen Container, die er startet, abrechnet, und er erzwingt ein Minimum von 2 Containern für autoskalierte Prozesstypen. Die Preise werden als Containergrößen angegeben (z. B. M sind 512 MB zu €0.02/Stunde; XL sind 2 GB zu €0.08/Stunde). DigitalOcean App Platform ist näher an 'Komponenten und Containern': Jeder Webservice/Worker ist seine eigene Containergröße, wird sekundengenau abgerechnet, und Instanztypen mit dedizierter CPU schalten AutoScaling frei. Die Gratisstufe deckt nur statische Sites ab, und Ausgehüberschuss kostet $0.02/GiB. Mir fällt auch auf, dass DigitalOcean "development databases" (nur PostgreSQL, standardmäßig nicht gesichert, mit der App gelöscht) von verwalteten Datenbankprodukten trennt, während das verwaltete Postgres von Scalingo tägliche verschlüsselte Backups und eine Point-in-Time-Wiederherstellung über 7 Tage beinhaltet.

AWS Activate ergibt am meisten Sinn für ein Startup, das in das breitere AWS-Ökosystem wachsen will, besonders wenn du spezialisierte Dienste benötigst, die Scalingo nicht abdeckt. Wenn ich etwas baue, das möglicherweise auf Amazon Bedrock (Drittanbieter-Fundamentmodelle über eine einzige API) zurückgreifen könnte, oder wenn ich weiß, dass ich VPC-Isolierung, IAM-Grenzen über Accounts hinweg und regionsspezifische Kontrollen benötige, ist AWS das Werkzeugset, das bereits vorhanden ist. Die Credits sind die Brücke: selbstfinanzierte Teams können mit dem Founders-Paket starten, und VC-/Inkubator-unterstützte Teams können den Portfolio-Weg (bis zu $100,000) anstreben, um das erste Jahr von Load Balancern, Datenbanken, Observability und Experimenten zu subventionieren. Der Trade-off, den ich einkalkuliere, ist der operative Overhead: du ersetzt Scalings „deploy + add-ons“-Ablauf durch mehrere Services, Infrastructure-as-Code und mehr Runbooks für Incidents.

Bei Scalingo ist die Plattformgrenze klar: Wähle eine Containergröße (S 256MB zu €0.01/hour bis 2XL 4GB zu €0.16/hour), deploye mit Buildpacks und skaliere dann horizontal mit dem integrierten Autoscaler. AWS Activate ist ein Startup-Credit-Programm, also ist das „Produkt“ eigentlich der AWS-Katalog plus dein Credit-Guthaben: Founders listet $1,000 an Credits und Portfolio wirbt mit bis zu $100,000 (mit Eligibility-Regeln wie pre Series B, Gründung innerhalb der letzten 10 Jahre und einem kostenpflichtigen AWS-Account). Architekturbedingt tauschst du eine einzige PaaS gegen viele Managed Services: Elastic Beanstalk oder ECS/Fargate für Compute, ECR für Images, Load Balancer + Auto Scaling für Traffic, RDS für relationale Daten und IAM/VPC für Identity und Netzwerk-Kontrollen. Der Vorteil sind die feinen Stellschrauben und die Service-Bandbreite; der Nachteil ist, dass es mehr Oberflächen zu konfigurieren und zu überwachen gibt als beim Scalingo-Modell „ein Dashboard + Add-ons“.

Scaleway passt gut, wenn ich einen echten Grund habe, Kubernetes selbst zu betreiben, etwa weil ich ein angepasstes Ingress‑Verhalten, Sidecars oder Cluster‑Level‑Policies brauche, und gleichzeitig meinen Stack im Footprint eines europäischen Anbieters behalten möchte. Die Preisseite macht die Aufteilung fix vs. variabel konkret: eine Mutualized Kapsule Control Plane kann Free sein, während eine Dedicated Control Plane bei etwa €80/month beginnt, und alles andere sind Worker Nodes plus Dienste wie Load Balancer und Volumes. Mir gefällt auch, dass das Kostenmodell des Container‑Registries transparent ist (private Image‑Speicherung zu €0.027/GB/month, eingehende Bandbreite kostenlos), was wichtig ist, wenn die CI ständig neue Images pusht. Für datenintensive Apps erlaubt mir S3‑kompatibler Object Storage, bestehende Werkzeuge wiederzuverwenden (SDKs, rclone, Backup‑Jobs) mit minimalen Codeänderungen, oft nur Endpoint‑ und Credentials‑Austausch.

Scalingo abstrahiert Container hinter Process‑Typen und Buildpacks und kann automatisch Review Apps pro PR/MR erstellen. Scaleway schiebt dich eine Ebene tiefer: Du entscheidest, ob du Kubernetes Kapsule, plain Instances oder eine Multi‑Cloud Control Plane mit Kubernetes Kosmos betreibst. Kapsule kann “Mutualized” (als Free gelistet) oder Dedicated sein (zum Beispiel Dedicated-4 zu €0.11/hour), und du zahlst dann separat für Worker Nodes, Load Balancer, Volumes und Networking. Für die Container‑Supply‑Chain berechnet Scaleways Registry Storage für private Images (€0.027/GB/month) und hält eingehende Bandbreite kostenlos. Beim Storage betrachte ich Scaleway Object Storage als Drop‑in‑Ersatz für S3, weil es eine S3‑kompatible API verwendet. Im Vergleich zur stündlichen Preisgestaltung pro Container bei Scalingo werden die Kosten bei Scaleway zur Summe aus Control Plane + Nodes + Add‑ons, was flexibler, aber weniger „eine Zahl pro Containergröße“ ist.