Heroku היה הדרך הטובה ביותר לפרוס אפליקציה ווב במשך שנים. הוא עדיין כזה — אם הצוות שלכם לפני product-market fit ולהוציא כסף על תשתיות זה בזבוז. אבל ברגע שעוברים את הנקודה הזאת, החשבון משתנה מהר. dyno סטנדרטי ב-Heroku עולה $25 לחודש. שני dynos לזמינות: $50 לחודש. הוסיפו Heroku Postgres ב-Standard-0: עוד $50 לחודש. אתם ב-$100+ לפני גדילה בתעבורה, תוספות, או scale אמיתי.
Google Cloud Run גובה רק על requests שמוגשים. סטארטאפ בתעבורה בינונית עם 10M requests לחודש ו-256MB-שנייה זמן מחשוב רץ בערך $20–40. פריסה ו-rollback ללא downtime מובנים. ואם אתם כבר ב-GCP לשירותים אחרים — ענן אחד פחות לנהל.
המדריך הזה עובר אתכם דרך המעבר בפועל — לא גרסת "תקראו את התיעוד ותגלו בעצמכם", אלא הרצף שעובד.
שלב 1: ביקורת Dockerfile — האם האפליקציה מתקינרת נכון?
Cloud Run דורש שהאפליקציה תרוץ בקונטיינר שמאזין על משתנה הסביבה PORT. לפני הכל, בדקו:
# טוב: קורא PORT מסביבה
CMD ["node", "server.js"] # server.js: const port = process.env.PORT || 3000;
# רע: מקודד פורט
EXPOSE 3000
CMD ["./myapp", "-port", "3000"]
תיקון: החליפו כל פורט מקודד ב-$PORT. Cloud Run מגדיר אותו ל-8080 כברירת מחדל, אבל ה-Dockerfile שלכם לא צריך להקשיח את הערך הזה.
גם בדקו:
- Stateless? קונטיינרים של Cloud Run יכולים להיסגר ולהפעיל מחדש בכל רגע. אם האפליקציה כותבת לדיסק מקומי (העלאות קבצים, מטמון, קבצים זמניים), עברו ל-Cloud Storage לפני המעבר.
- זמן הפעלה. Cloud Run יכול לסקייל ל-zero. אם האפליקציה לוקחת 30 שניות להפעיל, cold starts יפגעו במשתמשים. מטרה: פחות מ-10 שניות.
- Health check. Cloud Run מצפה שהקונטיינר יתחיל לקבל תעבורה על
PORTמהר. הוסיפו endpoint פשוטGET /healthשמחזיר200 OK.
שלב 2: העברת env vars ל-Secret Manager
ב-Heroku הגדרתם heroku config:set DATABASE_URL=.... ב-Cloud Run יש שתי אפשרויות:
- משתני סביבה של Cloud Run — מתאים לconfig לא-רגיש (feature flags, כתובות שירותים, רמות לוג)
- GCP Secret Manager — נדרש לכל דבר רגיש (סיסמאות DB, מפתחות API, סודות OAuth)
לכל סוד מ-Heroku:
# יצירת הסוד
echo -n "your-secret-value" | gcloud secrets create DATABASE_URL
--data-file=-
# מתן גישה לשירות Cloud Run
gcloud secrets add-iam-policy-binding DATABASE_URL
--member="serviceAccount:your-sa@your-project.iam.gserviceaccount.com"
--role="roles/secretmanager.secretAccessor"
בהגדרות שירות Cloud Run שלכם, רכבו את הסוד כמשתנה סביבה. קוד האפליקציה לא משתנה — הוא עדיין קורא process.env.DATABASE_URL. רק המקור משתנה משכבת ה-config של Heroku ל-GCP Secret Manager.
אל תשכחו להעביר את Heroku Postgres. אפשרויות:
- Cloud SQL (PostgreSQL) — Postgres מנוהל ב-GCP, מאפיינים שקולים, עלות נמוכה יותר ברוב הרמות
- Neon, Supabase — אפשרויות Postgres serverless שמשתלבות טבעית עם מודל scale-to-zero של Cloud Run
למעבר DB ללא downtime, השתמשו ב-pg_dump ו-pg_restore בשעות נמוכות תנועה, ואז החליפו את connection string.
שלב 3: הפריסה הראשונה ל-Cloud Run
ברגע שהקונטיינר מוכן והסודות ב-Secret Manager:
# בנייה ודחיפה ל-Artifact Registry
gcloud builds submit --tag gcr.io/YOUR_PROJECT/myapp:latest
# פריסה ל-Cloud Run
gcloud run deploy myapp
--image gcr.io/YOUR_PROJECT/myapp:latest
--region us-central1
--allow-unauthenticated
--set-env-vars "NODE_ENV=production"
--update-secrets="DATABASE_URL=DATABASE_URL:latest"
--min-instances 0
--max-instances 10
Cloud Run נותן לכם URL של *.run.app מיד. בדקו אותו לעומק לפני שנוגעים ב-DNS.
פיצול תעבורה במהלך ה-rollout: Cloud Run מאפשר פיצול תעבורה בין revisions. השתמשו בזה למעבר הראשון:
# פריסת revision חדש, שליחת 10% מהתעבורה אליו
gcloud run services update-traffic myapp
--to-revisions=REVISION_ID=10,PREVIOUS_REVISION=90
עקבו אחרי שיעורי שגיאות 15–30 דקות. אם יציבים — העלו ל-50%, אחר כך ל-100%.
שלב 4: Rollback תוך 30 שניות
אם ה-revision החדש מציג בעיות, rollback הוא פקודה אחת:
gcloud run services update-traffic myapp
--to-revisions=PREVIOUS_REVISION=100
או לחצו "Edit traffic" ב-Cloud Console. בשונה מ-Heroku — שם git push heroku main עם commit בעייתי משאיר אתכם מתרוצצים לבטל ולדחוף מחדש — Cloud Run שומר את כל ה-revisions הקודמים חיים עד שמוחקים אותם ידנית. ה-rollback מיידי, לא פריסה מחדש.
שלב 5: ניתוב DNS
לאחר שה-revision החדש יציב ומגיש תעבורת בדיקות:
- הוסיפו custom domain: Cloud Console → Cloud Run → השירות שלכם → Manage Custom Domains
- הוסיפו רשומת
CNAMEאוAלפי מה שCloud Run מראה לכם - המתינו להפצה (5 דקות עד כמה שעות בהתאם ל-TTL)
- וודאו ש-HTTPS פעיל — Cloud Run מפרסם תעודת TLS מנוהלת אוטומטית
- הסירו את ה-custom domain הישן מ-Heroku
השאירו את אפליקציית Heroku רצה 48 שעות לאחר ניתוב DNS, ליתר ביטחון.
השוואת עלויות: Heroku מול Cloud Run
| הגדרה | Heroku | Cloud Run |
|---|---|---|
| 2 dynos (Standard-2x) | $100/חודש | ~$15–30/חודש |
| Postgres (Standard-0, 25 GB) | $50/חודש | Cloud SQL ~$25/חודש |
| Custom domain + SSL | כלול | כלול |
| Auto-scaling | תוסף בתשלום | מובנה |
| פריסה ללא downtime | מובנה | מובנה |
| Rollback | פריסה מחדש ידנית | פיצול תעבורה לפי revision |
| סה"כ טיפוסי לסטארטאפ | $150–300+/חודש | $40–80/חודש |
הפער גדל ב-scale. תמחור dyno של Heroku קבוע ללא קשר לתעבורה. מודל per-request של Cloud Run אומר שסוף שבוע שקט כמעט לא עולה כלום.
מכשולים נפוצים
Sticky sessions. Cloud Run הוא stateless ומאוזן על פני instances. אם האפליקציה תלויה ב-sticky sessions (נפוץ עם Socket.io או session stores בצד שרת), העברו מצב session ל-Redis (Cloud Memorystore) לפני המעבר.
עבודות מתוזמנות (Heroku Scheduler). ל-Cloud Run אין scheduler מובנה. השתמשו ב-Cloud Scheduler כדי להפעיל Cloud Run job לפי לוח זמנים cron, או עברו ל-Cloud Tasks לעבודות מבוססות תור.
Background workers. אם אתם משתמשים ב-worker dynos של Heroku לצרכני תור, פרסו אותם כשירות Cloud Run נפרד עם --min-instances 1 כדי שלא יסקייל ל-zero בזמן המתנה להודעות.
אפליקציות WebSocket. Cloud Run תומך ב-WebSockets, אבל צריך HTTP/2 מופעל והsessions לא sticky. ארכיטקטו reconnection בצד ה-client.
המעבר במבט אחד
| שלב | מה לעשות | מה לשים לב |
|---|---|---|
| 1. ביקורת Dockerfile | PORT מסביבה, stateless, הפעלה מהירה |
פורטים מקודדים, כתיבה לדיסק |
| 2. סודות | מעבר ל-Secret Manager, הרשאה ל-SA | אל תשכחו credentials של DB |
| 3. פריסה ראשונה | gcloud run deploy, בדיקה על *.run.app |
cold start, health check |
| 4. פיצול תעבורה | 10% ← 50% ← 100%, מעקב שגיאות | עלייה בשגיאות = rollback |
| 5. ניתוב DNS | custom domain, TLS מנוהל | השאירו Heroku פעיל 48 שעות |
מה הלאה
Cloud Run הוא צעד טבעי מעלה מ-Heroku — אותה פשטות, כלכלה טובה יותר, וגדל עמכם מ-100 ל-1M משתמשים ללא ארכיטקטורה מחדש. ברגע שאתם ב-Cloud Run, הצעד הבא הוא חיבור pipeline CI/CD מסודר כך שכל push ל-main יבנה, יבדוק ויפרס אוטומטית — בלי שאף אחד ירוץ gcloud run deploy ידנית.
קראו צ׳קליסט ה-CI/CD הראשון שלכם להגדרה המדויקת, ומדריך ה-DevOps לסטארטאפ לתמונת הפלטפורמה המלאה.
מבצעים מעבר מ-Heroku או VM ורוצים שמישהו יבדוק את ה-setup שלכם לפני ניתוב ה-DNS? הזמינו שיחת היכרות חינם — נבחן את הארכיטקטורה שלכם ונמסור לכם תוכנית מעבר.