PaaS-priser: bruksbaserte kostnader kontra faste instanskostnader
PaaS-priser forklart: sammenlign minuttbasert bruk med faste instansavgifter, beregn kostnader for CPU/RAM/disk, forstå Dockup-planene og lag trygge prognoser.
PaaS-priser kan se enkle ut på et plankort, men bli forvirrende i produksjon. Et abonnement kan inkludere brukskreditt, en fast instans kan ta betalt for en reservert størrelse, og en bruksbasert plattform kan måle faktisk bruk av CPU, RAM og disk. Hvis du bare sammenligner det første beløpet, tar du en feil beslutning.
Dockup skiller planabonnementet fra målt forbruk. Free inneholder en engangs startkreditt; Pro inneholder månedlig forbrukskreditt. CPU-, RAM- og diskbruk måles per minutt og trekkes fra saldoen.
Hva er forskjellen på bruksbaserte priser og priser for faste instanser?
Faste instanspriser beregnes ut fra en valgt maskin- eller tjenestestørrelse for faktureringsperioden, uavhengig av om applikasjonen bruker all den reserverte kapasiteten. Bruksbaserte priser beregnes ut fra målt forbruk, noen ganger med minsteforbruk eller kreditt inkludert i planen.
| Modell | Hovedenhet | Fordel | Risiko |
|---|---|---|---|
| Fast instans | Valgt størrelse over tid | Forutsigbar kostnadslinje | Du betaler for ubrukt kapasitet |
| Faktisk bruk | CPU/RAM/disk brukt over tid | Regningen samsvarer med forbruket | Variabel prognose |
| Abonnement pluss kreditt | Plangebyr og inkludert saldo | Kombinerer tilgang og forbruk | Kreditten kan misforstås |
| Serverless-forespørsel | Kall/varighet | Skalerer til null for enkelte arbeidsbelastninger | Kostnadshopp ved høyt volum |
| Sete pluss ressurs | Teamtilgang pluss compute | Samarbeidsfunksjoner | Vekst per sete |
Dockup bruker abonnement pluss brukskreditt. Betalte planer har ingen begrensning på antall ressurser, men compute og disk er ikke gratis. «Ubegrensede deployments» betyr at det ikke er noen grense for hvor mange deployments du kan opprette. Ressursene de bruker, trekkes fortsatt fra plansaldoen.
Måling per minutt er mer detaljert enn en månedlig fast instans. En tjeneste som er stoppet deler av måneden, kan bruke mindre enn en tjeneste som kjører kontinuerlig, mens en alltid aktiv og belastet tjeneste kan bruke opp den tilgjengelige saldoen jevnt.
Hvilke Dockup-planer og hvilken inkludert kreditt finnes?
Planoversikten er:
| Plan | Pris | Inkludert kreditt | Begrensninger for workspace/database/deployment |
|---|---|---|---|
| Free | $0/måned | $10 i startkreditt | 1 workspace, 3 databaser, 3 deployments |
| Hobby | $5/måned | $0 | Ubegrenset på betalte planer |
| Pro | $20/måned | $20 i månedlig brukskreditt | Ubegrenset; anbefalt |
CPU-, RAM- og diskforbruk trekkes fra saldoen. Når du vurderer en betalt plan, bør du se på månedsbeløpet som både tilgang til ubegrenset antall ressurser og en forhåndsbetalt brukssaldo på samme beløp.
Pro-planen anbefales fordi den gir $20 i månedlig kreditt og samtidig rom for flere små tjenester eller en representativ produksjonsarbeidsbelastning. Riktig plan avhenger likevel av det faktiske forbruket.
Se kontosaldo og tjenesteforbruk i app.dockup.ai. Se CPU, minne, disk og gjeldende plansaldo i sammenheng, i stedet for å behandle abonnementsbeløpet som hele regningen.
Hvordan beregner du en realistisk PaaS-kostnad?
Bygg estimatet basert på workload-timer og målte ressurser.
En enkel konseptuell formel er:
månedlig kostnad =
abonnement
+ CPU-forbruk
+ RAM-forbruk
+ diskforbruk
+ andre målte tjenester
- inkludert brukskreditt
De nøyaktige enhetsprisene bør hentes fra den gjeldende priskilden, ikke fra et kopiert regneark som ingen oppdaterer. Metoden er fortsatt den samme.
Registrer følgende for hver tjeneste:
- Antall timer den kjører per dag.
- Gjennomsnittlig og maksimal CPU-bruk.
- Gjennomsnittlig arbeidssett for minne.
- Størrelse og vekst for persistent disk.
- Database-ressurser.
- Levetid for preview-miljøer.
- Antall miljøer.
- Sesongvariasjoner i trafikken.
- Forventet frekvens for builds og deployments.
Bruk målte verdier etter lansering. Forespurt minne er ikke det samme som faktisk minneforbruk i en bruksbasert modell. En fast instansregning kan derimot baseres på den forespurte størrelsen selv når den faktiske utnyttelsen er lav.
Eksempel på arbeidsark for arbeidsbelastning
| Ressurs | Antall | Kjøremønster | Sikkerhet |
|---|---|---|---|
| Webtjeneste | 1 | 24/7 | Høy |
| Worker | 1 | 8 timer/dag | Middels |
| PostgreSQL | 1 | 24/7 | Høy |
| Redis | 1 | 24/7 | Middels |
| Preview-tjeneste | 3 i gjennomsnitt | 6 timer hver | Lav |
| Volume | 20 GB | Kontinuerlig | Høy |
Ikke gjør denne tabellen om til en kunstig prisreferanse uten oppdaterte enhetspriser og reell utnyttelse. Den er en etterspørselsmodell.
Når sparer bruksbaserte priser penger?
Bruksbasert fakturering er attraktivt når arbeidsbelastningen varierer, kan stoppes når den er inaktiv, eller har et stort gap mellom ønsket maksimum og faktisk forbruk.
Eksempler:
- Utviklingsmiljøer som bare brukes i arbeidstiden.
- Preview-deployments som bare eksisterer under en review.
- Batch-workere som bare er aktive i et begrenset tidsrom.
- Tidlige produkter med lav grunntrafikk.
- Tjenester som kan stoppes mellom kampanjer.
- Små API-er med lav gjennomsnittlig CPU-bruk.
En fast instans kan være konkurransedyktig når arbeidsbelastningen er kontinuerlig høy og forutsigbar. Da kan teamet foretrekke en stabil, reservert pris fremfor detaljert måling.
Bruksbaserte besparelser forutsetter at arbeidsbelastningen faktisk bruker færre ressurser. Definer en støttet livssyklus for reelt inaktive utviklingsmiljøer, og bekreft den faktiske oppførselen i plattformen i stedet for å anta at en tjeneste som ser inaktiv ut, ikke koster noe.
Livssyklusen til preview-miljøer er også viktig. Et team som lar dusinvis av previews kjøre, kan spise opp kostnadsfordelen ved kortvarige miljøer. Definer eierskap og utløpstid.
Hvordan påvirker databaser, volumes og previews PaaS-priser?
Compute for applikasjonen er bare én kostnadslinje.
Administrerte databaser
PostgreSQL, MySQL, MongoDB og Redis bruker CPU, RAM og disk. Databasearbeidsbelastninger er ofte alltid aktive, og lagringsbehovet vokser over tid. Ta med krav til backups og migrering i driftsmodellen, selv når de ikke er egne begrensninger i planen.
Persistente volumes
Volumes beholder data på tvers av deployments og bruker disk kontinuerlig. Følg med på det faktiske forbruket:
dockup volume usage <volumeId> production/web --json
En allokering på 20 GB med 2 GB i bruk kan bety rom for vekst eller sløsing. Beslutningen avhenger av hvordan Dockup måler disk, og av applikasjonens forventede vekst på kort sikt.
Preview-deployments
Hver PR eller branch kan få et isolert miljø og en URL. En preview bruker ressurser så lenge den er aktiv. Previews i et privat nettverk kan også spørre produksjonsdatabasen gjennom en automatisk skrivebeskyttet bruker, noe som kan øke belastningen på databasen uten at det opprettes en separat database.
Windows-VM-er og Linux-maskiner
Compute på OS-nivå kan ha et større jevnt ressursforbruk enn en liten applikasjonscontainer. Dimensjoner basert på målte programvarekrav, og steng eller fjern midlertidige ressurser når oppgaven er fullført.
Antall ressurser er ubegrenset på betalte planer, så governance må erstatte harde antallsgrenser. En agent bør ikke opprette ti testtjenester bare fordi plattformen tillater det.
Hvordan sammenligner du PaaS-leverandører uten å lure deg selv?
Normaliser arbeidsbelastningen først. En rettferdig sammenligning bruker samme:
- CPU- og minnebehov.
- Antall driftstimer.
- Databasemotor og lagring.
- Persistent disk.
- Antall previews og levetiden deres.
- Team-seter når disse faktureres.
- Forutsetninger for nettverksoverføring.
- Krav til backup og support.
- Regioner og tilgjengelighetsmodell.
- Operativt arbeid.
Klassifiser deretter hver kostnad som fast, målt, kreditert eller usikker.
| Kostnadslinje | Leverandør A | Leverandør B | Dockup |
|---|---|---|---|
| Abonnement | Registrer gjeldende pris | Registrer gjeldende pris | $0/$5/$20 |
| Inkludert bruk | Registrer gjeldende | Registrer gjeldende | $10 start eller månedlig kreditt tilsvarende planen |
| CPU | Fast eller målt | Fast eller målt | Måles per minutt |
| RAM | Fast eller målt | Fast eller målt | Måles per minutt |
| Disk | Registrer gjeldende | Registrer gjeldende | Måles per minutt |
| Database | Separat eller inkludert | Separat eller inkludert | Forbruk av administrerte ressurser |
| Previews | Modellér levetid | Modellér levetid | Ressursforbruk mens de er aktive |
| Seter | Registrer gjeldende | Registrer gjeldende | Bekreft gjeldende vilkår for teamplaner |
Unngå tre vanlige feil:
- Å sammenligne en produksjonstjeneste på én plattform med en sovende gratistjeneste på en annen.
- Å trekke fra inkludert kreditt to ganger.
- Å tolke ubegrenset antall ressurser som ubegrenset bruk.
Artikkelen Dockup vs Render vs Fly.io bruker denne metoden uten å låse konkurrentenes priser.
Hvordan bør team overvåke og kontrollere PaaS-forbruket?
Kostnadskontroll er en kontinuerlig driftsprosess. Se gjennom tjenesteforbruk og kontosaldo i app.dockup.ai, og knytt deretter endringer til deployments, trafikk og ressursvekst.
Fordel eierskap til ressursene. Hver tjeneste, database, volume, Windows-VM, Linux-maskin og preview bør ha et formål og en eier. Slett eller stopp ubrukte ressurser gjennom en godkjent prosess.
En AI-agent kan hjelpe ved å liste ressurser, oppsummere bruk og foreslå tiltak. Den bør ikke slette ressurser autonomt bare basert på lav aktivitet. En database for hendelsesgjenoppretting eller en sjelden brukt administrativ tjeneste kan være inaktiv med hensikt.
Budsjettgrenser
Definer:
- Forventet månedlig intervall.
- Varselgrense.
- Grense for nærmere undersøkelse.
- Krav om godkjenning for nye alltid aktive ressurser.
- Maksimal levetid for previews.
- Grense for volumvekst.
- Eier for uforklarte kostnader.
En prognose er et intervall, ikke et løfte. Bruk høye, forventede og lave scenarier for trafikk og preview-aktivitet.
Enhetsøkonomi
Knytt infrastrukturkostnadene til en produkteenhet: aktiv kunde, behandlet jobb, API-forespørsel eller generert artefakt. Totalkostnaden kan øke samtidig som kostnaden per enhet går ned. Et fast abonnement på $20 kan også se billig ut, mens ubrukte tjenester skaper operasjonell kompleksitet.
Kostnaden ved utviklertid
En lavere plattformregning kan være et dårligere valg hvis teamet må bygge og vedlikeholde wrappers for deployments, overvåking, preview-orkestrering, backups eller agentsikkerhet. Ta med operativt arbeid og risiko for hendelser.
Dockups verdiforslag handler ikke bare om pristabellen. Det kombinerer deploymentlaget for AI-agenter med administrerte tjenester og drift gjennom én CLI.
En valideringsplan på 30 dager
- Start med den minste planen som støtter testen.
- Deploy en representativ tjeneste og database.
- Kjør realistisk trafikk eller arbeidsbelastning.
- La previews kjøre bare så lenge en normal review varer.
- Følg med på forbruket ukentlig.
- Se på vekst i volume og database.
- Sammenlign prognosen med den faktiske kostnaden ved månedsslutt.
- Bytt plan bare basert på dokumenterte data.
Free-planen gir $10 i startkreditt for en innledende validering. Pro-planen gir en månedlig saldo på $20 for en bredere produksjonstest.
Den endelige PaaS-prisbeslutningen
PaaS-priser er forståelige når hver linje har en enhet, tidsperiode og regel for eierskap. Bruksbasert måling belønner effektive arbeidsbelastninger med variabel aktivitet, mens faste instanser belønner forutsigbarhet når kapasiteten trengs kontinuerlig.
Dockups modell med CPU, RAM og disk målt per minutt bør vurderes ut fra faktisk tjenesteforbruk. Velg planen som gir riktig inkludert saldo og riktige kontofunksjoner, og fortsett deretter å måle i stedet for å anta at abonnementsavgiften begrenser alt forbruk.
Bruk Dockup CLI-referansen for gjeldende brukskommandoer. Sammenlign nærliggende plattformer i Dockup vs Railway og Dockup vs Heroku, og sjekk deres gjeldende offisielle priser før publisering.
Skill kontantstrøm fra økonomisk kostnad
Inkludert kreditt påvirker når pengene trekkes fra kontoen, men gjør ikke arbeidsbelastningen gratis. Følg med på brutto ressursforbruk og netto beløp som skal betales. Bruttoforbruk viser effektivitet, mens nettoforbruk viser kontanteffekten.
En Pro-plan gir for eksempel $20 i månedlig kreditt. Hvis målte ressurser bruker mindre enn saldoen, kan kontantbelastningen fortsatt være abonnementsprisen på $20. Hvis forbruket overstiger saldoen, blir det overskytende en ekstra kostnad. Det nøyaktige resultatet avhenger av gjeldende måling og kontosaldo.
Bruk rapporter for PaaS-priser som viser begge tallene, slik at teamene ikke optimaliserer først etter at kreditten er brukt opp.
Modellér usikkerhet eksplisitt
Tidlige prognoser bør ha tre scenarier:
| Variabel | Lav | Forventet | Høy |
|---|---|---|---|
| Trafikk | 50 % av planen | Prognose | 200 % av planen |
| Preview-levetid | 2 timer | 8 timer | 3 dager |
| Databasevekst | 1 GB/mnd. | 5 GB/mnd. | 20 GB/mnd. |
| Worker-aktivitet | 2 t/dag | 8 t/dag | 24 t/dag |
| Hendelsesoverhead | Ingen | Én gjenoppretting | Gjentatt feilsøking |
Bruk gjeldende enhetspriser i hvert scenario. Målet er ikke presisjon ned til centen, men å identifisere hvilken antakelse som kan endre beslutningen.
En fast instans innebærer også usikkerhet: Teamet kan vokse ut av den valgte størrelsen og måtte hoppe til neste nivå. Ta med slike sprang i kostnaden.
Ta med multiplisering på tvers av miljøer
En produksjonsarkitektur består sjelden av bare én tjeneste. Tell staging, previews, workere, databaser, Redis, volumes, Windows-VM-er, Linux-maskiner og midlertidige migreringsressurser.
Én liten tjeneste kan passe godt innenfor startkreditten. Den samme tjenesten på tvers av produksjon, staging og fem permanente previews er et helt annet PaaS-pris-problem.
Definer hvilke miljøer som kjører kontinuerlig:
- Produksjon: normalt alltid aktiv.
- Staging: alltid aktiv bare når det er nødvendig.
- Preview: knyttet til en åpen PR eller branch.
- Lasttest: opprettes for et planlagt tidsrom.
- Migrering: fjernes etter validering.
- Katastrofegjenoppretting: kostnadsberegnes ut fra ønsket beredskapsnivå.
Ubegrenset antall på en betalt plan gjør denne styringen viktigere, ikke mindre viktig.
Sammenlign optimaliseringsvalg med risiko
Å redusere minne, stoppe en worker, korte ned retention eller slette et volume kan redusere kostnadene, men hvert tiltak påvirker påliteligheten. Dokumenter konsekvensen for tjenesten sammen med den estimerte besparelsen.
Et nyttig optimaliseringsforslag inneholder:
- Ressurs og eier.
- Gjeldende målte forbruk.
- Foreslått endring.
- Forventet månedlig intervall.
- Risiko for ytelse eller gjenoppretting.
- Metode for tilbakerulling.
- Observasjonsperiode.
En agent kan oppsummere det målte forbruket som vises av plattformen, men et menneske bør godkjenne endringer som kan påvirke tilgjengelighet eller dataretensjon.
Evaluer PaaS-priser på nytt etter arkitekturendringer
En ny cache kan redusere CPU-bruken i databasen, samtidig som den øker kostnaden for Redis. En bakgrunnsworker kan forbedre API-latens, men kjøre flere timer. Privat nettverk kan endre arkitekturen uten å endre de samme grunnleggende CPU/RAM/disk-enhetene. En Dockerfile kan redusere bildestørrelsen, men kreve utviklertid.
Lag en ny prognose etter:
- At du legger til en administrert database.
- At du aktiverer mange previews.
- At du kobler til et stort volume.
- At du går over til Kubernetes-autoskalering.
- At du oppretter en Windows-VM eller Linux-maskin.
- At du endrer retention.
- At du lanserer en ny region eller kundetype.
PaaS-priser er en levende modell knyttet til arkitekturen, ikke et engangsregneark for innkjøp.
Mal for månedlig gjennomgang
Registrer plan, startsaldo, bruttoforbruk, gjenværende saldo, de fem største ressursene, uventede endringer, stoppede ressurser, antall previews, diskvekst og scenarier for neste måned.
Sammenlign resultatet med forrige måned, og noter deployments eller trafikkhendelser som forklarer avviket. Da blir kostnadsgjennomgangen nyttig for engineering i stedet for en overraskelse for økonomiavdelingen.
Den samme malen kan brukes til å sammenligne leverandører av faste instanser: Bytt ut de målte ressurslinjene med valgte instansavgifter, og ta med utnyttelse slik at ubrukt kapasitet fortsatt er synlig.
Publiser antakelser med hvert estimat
Et tall for PaaS-priser uten antakelser kan ikke etterprøves. Legg ved kjøretimer, ressursbruk, diskvekst, preview-levetid, antall databaser og datoen for gjeldende enhetspriser. Merk verdier som målte, estimerte eller ukjente.
Oppdater modellen etter den første uken og den første hele måneden. Forskjellen mellom prognose og faktiske tall er informasjon om arbeidsbelastningen, ikke bare en regnskapsfeil.
Denne praksisen holder sammenligninger av PaaS-priser gyldige når leverandører endrer prisene eller arkitekturen vokser.
Hold modellen versjonert
Commit antakelsene og datoen for gjennomgangen sammen med arkitekturnotatene. En versjonert modell for PaaS-priser viser hvorfor teamet endret planer, og hindrer at et gammelt regneark blir et uforklart budsjettmål.
Start med en deployment som kan etterprøves
Deploy én representativ arbeidsbelastning, følg den i 30 dager, og sammenlign målt forbruk for tjenester, database, previews og disk med plansaldoen.
Start gratis på app.dockup.ai. Free-planen koster $0 per måned, inkluderer $10 i startkreditt og støtter ett workspace, tre databaser og tre deployments.
Vanlige spørsmål
Hvor mye koster Dockup?
Free koster $0 med $10 i startkreditt. Hobby koster $5 per måned, der forbruk faktureres i tillegg, og Pro koster $20 per måned med de første $20 i forbruk inkludert.
Hva er ubegrenset på Dockups betalte planer?
Betalte planer tillater ubegrenset antall workspaces, databaser og deployments. CPU-, RAM- og diskforbruk bruker fortsatt plansaldoen.
Hvordan måles Dockup-forbruk?
CPU-, RAM- og diskforbruk måles per minutt og trekkes fra den inkluderte eller påfylte saldoen på kontoen.
Er bruksbaserte priser alltid billigere enn en fast instans?
Nei. Det kan gi besparelser for variable eller inaktive arbeidsbelastninger, mens en kontinuerlig travel og forutsigbar arbeidsbelastning kan sammenlignes godt med en fast instans. Modellér samme behov.
Hvordan bør jeg sammenligne to PaaS-priser?
Normaliser driftstimer, CPU, minne, disk, databaser, previews, dataoverføring, seter og support. Identifiser deretter faste avgifter, målt bruk, inkluderte kreditter og usikkerhet.