Prezzi PaaS: costi basati sull'utilizzo o costi fissi delle istanze

I prezzi PaaS possono sembrare semplici nella scheda di un piano e diventare confusi in produzione. Un costo di abbonamento può includere credito per l'utilizzo, un'istanza fissa può addebitare la dimensione riservata e una piattaforma basata sull'utilizzo può misurare CPU, RAM e disco effettivamente consumati. Confrontare soltanto il primo importo in dollari porta a una decisione sbagliata.

Dockup separa l'abbonamento al piano dal consumo misurato. Free include un credito iniziale una tantum; Pro include credito di utilizzo mensile. Il consumo di CPU, RAM e disco viene misurato al minuto e detratto dal saldo.

Qual è la differenza tra prezzi basati sull'utilizzo e prezzi fissi delle istanze?

I prezzi fissi delle istanze addebitano una macchina o una dimensione di servizio selezionata per il periodo di fatturazione, indipendentemente dal fatto che l'applicazione utilizzi o meno tutta la capacità riservata. I prezzi basati sull'utilizzo addebitano il consumo misurato, talvolta con minimi o crediti inclusi nel piano.

Modello	Unità principale	Vantaggio	Rischio
Istanza fissa	Dimensione selezionata nel tempo	Voce di costo prevedibile	Si paga la capacità inutilizzata
Utilizzo effettivo	CPU/RAM/disco consumati nel tempo	Allinea la fattura al consumo	Previsione variabile
Abbonamento più credito	Costo del piano e saldo incluso	Combina accesso e spesa	Il credito può essere frainteso
Richiesta serverless	Invocazioni/durata	In alcuni casi scala fino a zero	Picchi di costo con volumi elevati
Posto più risorse	Accesso del team più capacità di calcolo	Funzionalità di collaborazione	Crescita per posto

Dockup usa un modello con abbonamento più credito per l'utilizzo. Il numero di risorse nei piani a pagamento è illimitato, ma il consumo di calcolo e disco non è gratuito. “Deployment illimitati” significa che non esiste un limite al numero di deployment che è possibile creare; le risorse consumate continuano a utilizzare il saldo del piano.

La misurazione al minuto è più granulare rispetto a un'istanza fissa mensile. Un servizio arrestato per parte del mese può consumare meno di uno in esecuzione continua, mentre un servizio sempre attivo e molto utilizzato può consumare regolarmente il saldo disponibile.

Quali sono i piani Dockup e i crediti inclusi?

La tabella dei piani è:

Piano	Prezzo	Credito incluso	Limiti di workspace/database/deployment
Free	$0/mese	$10 di credito iniziale	1 workspace, 3 database, 3 deployment
Hobby	$5/mese	$0	Illimitati nei piani a pagamento
Pro	$20/mese	$20 di credito mensile per l'utilizzo	Illimitati; consigliato

Il consumo di CPU, RAM e disco viene sottratto dal saldo. Quando valuti un piano a pagamento, considera il costo sia come accesso a un numero illimitato di risorse, sia come saldo prepagato per l'utilizzo dello stesso importo.

Il piano Pro è consigliato perché offre $20 di credito mensile, lasciando spazio per diversi servizi di piccole dimensioni o per un carico di lavoro rappresentativo in produzione. Il piano più adatto dipende comunque dal consumo effettivo.

Controlla il saldo dell'account e il consumo dei servizi in app.dockup.ai. Esamina insieme CPU, memoria, disco e saldo attuale del piano, invece di considerare l'importo dell'abbonamento come l'intera fattura.

Come si calcola un costo PaaS realistico?

Costruisci la stima a partire dalle ore di utilizzo del workload e dalle risorse effettivamente misurate.

Una formula concettuale semplice è:

costo mensile =
  abbonamento
  + consumo CPU
  + consumo RAM
  + consumo disco
  + altri servizi misurati
  - credito incluso per l'utilizzo

Le tariffe esatte per unità devono essere ricavate dalla fonte dei prezzi aggiornata, non da un foglio di calcolo copiato che nessuno aggiorna. La metodologia rimane stabile.

Per ogni servizio, registra:

• Ore di esecuzione al giorno.
• Utilizzo medio e di picco della CPU.
• Working set medio della memoria.
• Dimensione e crescita del disco persistente.
• Risorse del database.
• Durata degli ambienti di preview.
• Numero di ambienti.
• Traffico stagionale.
• Frequenza prevista di build e deployment.

Dopo il lancio, usa valori misurati. La memoria richiesta non equivale al consumo effettivo di memoria in un modello basato sull'utilizzo. Al contrario, il costo di un'istanza fissa può riflettere la dimensione richiesta anche quando l'utilizzo effettivo è basso.

Esempio di foglio di lavoro del carico

Risorsa	Quantità	Modalità di esecuzione	Affidabilità
Servizio web	1	24/7	Alta
Worker	1	8 ore/giorno	Media
PostgreSQL	1	24/7	Alta
Redis	1	24/7	Media
Servizio di preview	3 in media	6 ore ciascuno	Bassa
Volume	20 GB	Continuativa	Alta

Non trasformare questa tabella in un benchmark fittizio in dollari senza prezzi correnti per unità e dati reali sull'utilizzo. Si tratta di un modello della domanda.

Quando i prezzi basati sull'utilizzo fanno risparmiare?

La fatturazione basata sull'utilizzo è interessante quando i workload sono variabili, possono essere arrestati quando inattivi o presentano una grande differenza tra il limite massimo richiesto e il consumo effettivo.

Ecco alcuni esempi:

• Ambienti di sviluppo utilizzati durante l'orario di lavoro.
• Deployment di preview esistenti solo durante la fase di revisione.
• Worker batch attivi per una finestra di tempo limitata.
• Prodotti nelle fasi iniziali con traffico di base ridotto.
• Servizi che possono essere arrestati tra una campagna e l'altra.
• API di piccole dimensioni con un utilizzo medio della CPU ridotto.

Un'istanza fissa può essere competitiva quando il workload è costantemente intenso e prevedibile. In questo caso, il team potrebbe preferire un prezzo riservato stabile rispetto alla misurazione granulare.

Il risparmio basato sull'utilizzo richiede che il workload consumi effettivamente meno risorse. Definisci un lifecycle supportato per gli ambienti di sviluppo realmente inattivi e verifica il comportamento attuale nella piattaforma invece di presumere che un servizio apparentemente inattivo non abbia costi.

Anche il lifecycle delle preview è importante. Un team che lascia decine di preview in esecuzione può annullare il vantaggio economico degli ambienti di breve durata. Definisci un responsabile e una scadenza.

In che modo database, volumi e preview incidono sui prezzi PaaS?

Il calcolo dell'applicazione rappresenta una sola voce.

Database gestiti

PostgreSQL, MySQL, MongoDB e Redis consumano CPU, RAM e disco. I workload dei database sono spesso sempre attivi e lo spazio di archiviazione cresce nel tempo. Includi backup e requisiti di migrazione nel modello operativo, anche quando non costituiscono limiti separati del piano.

Volumi persistenti

I volumi conservano i dati tra un deployment e l'altro e consumano continuamente spazio su disco. Monitora l'utilizzo effettivo:

dockup volume usage <volumeId> production/web --json

Un'allocazione di 20 GB con 2 GB utilizzati può indicare margine per la crescita o spreco. La decisione dipende dal modo in cui Dockup misura il disco e dalla crescita prevista a breve termine dell'applicazione.

Deployment di preview

Ogni PR o branch può ricevere un ambiente e un URL isolati. Una preview consuma risorse mentre è attiva. Le preview su rete privata possono inoltre interrogare il database di produzione tramite un utente automatico di sola lettura, aggiungendo carico al database anche senza un database separato.

VM Windows e macchine Linux

Il calcolo a livello di sistema operativo può avere un footprint stabile maggiore rispetto a un piccolo container applicativo. Dimensiona in base ai requisiti software misurati e arresta o dismetti le risorse temporanee quando il relativo task è terminato.

Nei piani a pagamento il numero di risorse è illimitato, quindi la governance deve sostituire i limiti rigidi sul numero. Un agente non dovrebbe creare dieci servizi di test solo perché la piattaforma lo consente.

Come si confrontano i provider PaaS senza trarre conclusioni fuorvianti?

Prima normalizza il workload. Un confronto corretto utilizza gli stessi:

1. Requisiti di CPU e memoria.
2. Ore di esecuzione.
3. Motore del database e spazio di archiviazione.
4. Disco persistente.
5. Numero e durata delle preview.
6. Posti del team, se addebitati.
7. Ipotesi sul trasferimento di rete.
8. Requisiti di backup e supporto.
9. Regioni e modello di disponibilità.
10. Lavoro operativo.

Poi classifica ogni voce come fissa, misurata, coperta da credito o incerta.

Voce di costo	Provider A	Provider B	Dockup
Abbonamento	Registra il valore attuale	Registra il valore attuale	$0/$5/$20
Utilizzo incluso	Registra il valore attuale	Registra il valore attuale	$10 iniziali o credito mensile corrispondente al piano
CPU	Fissa o misurata	Fissa o misurata	Misurata al minuto
RAM	Fissa o misurata	Fissa o misurata	Misurata al minuto
Disco	Registra il valore attuale	Registra il valore attuale	Misurato al minuto
Database	Separato o incluso	Separato o incluso	Consumo delle risorse gestite
Preview	Modella la durata	Modella la durata	Consumo delle risorse durante l'attività
Posti	Registra il valore attuale	Registra il valore attuale	Verifica le condizioni attuali del piano team

Evita tre errori comuni:

• Confrontare un servizio di produzione su una piattaforma con un servizio in pausa su un'altra.
• Sottrarre due volte il credito incluso.
• Confondere il numero illimitato di risorse con un utilizzo illimitato.

L'articolo Dockup vs Render vs Fly.io applica questo metodo senza fissare i prezzi dei competitor.

Come possono i team monitorare e controllare la spesa PaaS?

Il controllo dei costi è un ciclo operativo. Esamina il consumo dei servizi e il saldo dell'account in app.dockup.ai, quindi collega le variazioni ai deployment, al traffico e alla crescita delle risorse.

Assegna la responsabilità delle risorse. Ogni servizio, database, volume, VM Windows, macchina Linux e preview dovrebbe avere uno scopo e un responsabile. Elimina o arresta le risorse inutilizzate tramite un processo approvato.

Un agente AI può aiutare elencando le risorse, riepilogando l'utilizzo e proponendo azioni. Non dovrebbe eliminare autonomamente le risorse basandosi soltanto su una bassa attività. Un database per il ripristino da incidenti o un servizio amministrativo usato raramente potrebbe essere intenzionalmente inattivo.

Soglie di budget

Definisci:

• Intervallo mensile previsto.
• Soglia di avviso.
• Soglia di analisi.
• Approvazione richiesta per le nuove risorse sempre attive.
• Durata massima delle preview.
• Soglia di crescita dei volumi.
• Responsabile della spesa non spiegata.

Una previsione è un intervallo, non una promessa. Utilizza scenari alto, previsto e basso per il traffico e l'attività delle preview.

Unit economics

Collega la spesa per l'infrastruttura a un'unità di prodotto: cliente attivo, job elaborato, richiesta API o artefatto generato. Il costo totale può aumentare mentre il costo per unità migliora. Anche un abbonamento fisso da $20 può sembrare conveniente, mentre i servizi inutilizzati creano complessità operativa.

Costo del tempo degli sviluppatori

Una fattura della piattaforma più bassa può rappresentare una decisione peggiore se il team deve creare e gestire wrapper di deployment, monitoring, orchestrazione delle preview, backup o sistemi di sicurezza per gli agenti. Includi il lavoro operativo e il rischio di incidenti.

La proposta di valore di Dockup non riguarda soltanto la tabella dei prezzi. Combina il deployment layer per gli agenti AI con servizi gestiti e operazioni tramite un'unica CLI.

Piano di validazione di 30 giorni

1. Inizia con il piano più piccolo che supporta il test.
2. Esegui il deployment di un servizio e di un database rappresentativi.
3. Genera traffico o workload realistici.
4. Mantieni le preview attive solo per la durata normale della revisione.
5. Monitora l'utilizzo ogni settimana.
6. Controlla la crescita del volume e del database.
7. Confronta la proiezione con la spesa effettiva a fine mese.
8. Cambia piano solo sulla base dei dati.

Il piano Free offre $10 di credito iniziale per una prima validazione. Il piano Pro offre un saldo mensile di $20 per un test di produzione più ampio.

Decisione finale sui prezzi PaaS

I prezzi PaaS sono comprensibili quando ogni voce ha un'unità, un periodo di riferimento e una regola di responsabilità. La misurazione basata sull'utilizzo favorisce i workload efficienti e intermittenti; le istanze fisse favoriscono la prevedibilità quando la capacità è necessaria in modo continuativo.

Il modello di Dockup, con CPU, RAM e disco misurati al minuto, deve essere valutato sulla base dell'utilizzo effettivo dei servizi. Scegli il piano che offre il saldo incluso e le funzionalità dell'account più adatti, quindi continua a misurare invece di presumere che il costo dell'abbonamento limiti tutto il consumo.

Usa la documentazione di riferimento della Dockup CLI per i comandi di utilizzo aggiornati. Confronta le piattaforme adiacenti in Dockup vs Railway e Dockup vs Heroku, verificando i prezzi ufficiali correnti prima della pubblicazione.

Separa il flusso di cassa dal costo economico

Il credito incluso modifica il momento in cui il denaro esce dall'account, ma non rende gratuito il workload. Monitora il consumo lordo delle risorse e l'importo netto dovuto. L'utilizzo lordo mostra l'efficienza; la spesa netta mostra l'impatto sul flusso di cassa.

Per esempio, un abbonamento Pro offre $20 di credito mensile. Se le risorse misurate consumano meno del saldo, l'addebito può restare pari ai $20 dell'abbonamento. Se il consumo supera il saldo, l'eccedenza diventa una spesa aggiuntiva. Il risultato esatto dipende dalla misurazione corrente e dal saldo dell'account.

Usa report sui prezzi PaaS che mostrino entrambi i valori, così i team non ottimizzano soltanto dopo aver esaurito il credito.

Modella esplicitamente l'incertezza

Le prime previsioni dovrebbero includere tre scenari:

Variabile	Basso	Previsto	Alto
Traffico	50% del piano	Previsione	200% del piano
Durata della preview	2 ore	8 ore	3 giorni
Crescita del database	1 GB/mese	5 GB/mese	20 GB/mese
Attività del worker	2 h/giorno	8 h/giorno	24 h/giorno
Overhead degli incidenti	Nessuno	Un ripristino	Debugging ripetuto

Applica le tariffe correnti per unità a ogni scenario. L'obiettivo non è una precisione al centesimo, ma identificare l'ipotesi che può cambiare la decisione.

Anche un'istanza fissa presenta elementi di incertezza: il team potrebbe superare la dimensione selezionata e passare al tier successivo. Includi questi cambiamenti a scatti.

Considera la moltiplicazione degli ambienti

Un'architettura di produzione raramente comprende un solo servizio. Conta staging, preview, worker, database, Redis, volumi, VM Windows, macchine Linux e risorse temporanee per le migrazioni.

Un singolo servizio di piccole dimensioni può rientrare comodamente nel credito iniziale. Lo stesso servizio distribuito tra produzione, staging e cinque preview persistenti rappresenta un problema di prezzi PaaS diverso.

Definisci quali ambienti vengono eseguiti continuamente:

• Produzione: normalmente sempre attiva.
• Staging: sempre attivo solo quando necessario.
• Preview: collegata a una PR o a un branch aperto.
• Load test: creato per una finestra programmata.
• Migrazione: rimosso dopo la validazione.
• Disaster recovery: calcolato in base all'obiettivo di disponibilità.

Il numero illimitato di risorse in un piano a pagamento rende questa governance più importante, non meno.

Confronta le scelte di ottimizzazione con i rischi

Ridurre la memoria, arrestare un worker, diminuire la retention o eliminare un volume può ridurre la spesa, ma ogni azione modifica l'affidabilità. Registra la conseguenza a livello di servizio accanto al risparmio stimato.

Una proposta di ottimizzazione utile contiene:

1. Risorsa e responsabile.
2. Consumo attuale misurato.
3. Modifica proposta.
4. Intervallo mensile previsto.
5. Rischio per le prestazioni o il ripristino.
6. Metodo di rollback.
7. Finestra di osservazione.

Un agente può riepilogare il consumo misurato mostrato dalla piattaforma, ma una persona dovrebbe approvare le modifiche che possono influire sulla disponibilità o sulla retention dei dati.

Rivedi i prezzi PaaS dopo le modifiche all'architettura

Una nuova cache può ridurre la CPU del database aggiungendo però il costo di Redis. Un worker in background può migliorare la latenza dell'API, ma restare in esecuzione per più ore. La rete privata può modificare l'architettura senza modificare le stesse unità fondamentali di CPU/RAM/disco. Un Dockerfile può ridurre le dimensioni dell'immagine, ma consumare tempo di sviluppo.

Crea una nuova previsione dopo:

• L'aggiunta di un database gestito.
• L'attivazione di numerose preview.
• Il collegamento di un volume di grandi dimensioni.
• Il passaggio all'autoscaling di Kubernetes.
• La creazione di una VM Windows o di una macchina Linux.
• La modifica della retention.
• Il lancio di una nuova regione o di un nuovo tier di clienti.

I prezzi PaaS sono un modello dinamico legato all'architettura, non un foglio di calcolo per gli acquisti da compilare una sola volta.

Modello per la revisione mensile

Registra il piano, il saldo iniziale, l'utilizzo lordo, il saldo rimanente, le cinque risorse principali, le variazioni impreviste, le risorse arrestate, il numero di preview, la crescita del disco e gli scenari per il mese successivo.

Confronta il risultato con il mese precedente e annota i deployment o gli eventi di traffico che spiegano la variazione. In questo modo la revisione dei costi diventa utile per l'engineering invece di trasformarsi in una sorpresa per il reparto finance.

Lo stesso modello può essere utilizzato per confrontare i provider con istanze fisse: sostituisci le voci relative alle risorse misurate con i costi delle istanze selezionate e includi l'utilizzo, così la capacità inutilizzata rimane visibile.

Pubblica le ipotesi con ogni stima

Un valore relativo ai prezzi PaaS senza ipotesi non può essere verificato. Allega le ore di esecuzione, l'utilizzo delle risorse, la crescita del disco, la durata delle preview, il numero di database e la data delle tariffe correnti per unità. Contrassegna i valori come misurati, stimati o sconosciuti.

Aggiorna il modello dopo la prima settimana e dopo il primo mese completo. La differenza tra previsione e dati effettivi fornisce informazioni sul workload, non è soltanto un errore contabile.

Questa disciplina mantiene validi i confronti dei prezzi PaaS quando i provider modificano le tariffe o l'architettura cresce.

Mantieni il modello versionato

Esegui il commit delle ipotesi e della data di revisione insieme alle note sull'architettura. Un modello versionato dei prezzi PaaS mostra perché il team ha cambiato piano e impedisce che un vecchio foglio di calcolo diventi un obiettivo di budget senza spiegazioni.

Inizia con un deployment verificabile

Esegui il deployment di un workload rappresentativo, osservalo per 30 giorni e confronta il consumo misurato di servizio, database, preview e disco con il saldo del piano.

Inizia gratuitamente su app.dockup.ai. Il piano Free costa $0 al mese, include $10 di credito iniziale e supporta un workspace, tre database e tre deployment.

FAQ

Quanto costa Dockup?

Free costa $0 e include $10 di credito iniziale. Hobby costa $5 al mese, con l'utilizzo fatturato a parte, e Pro costa $20 al mese con i primi $20 di utilizzo inclusi.

Cosa è illimitato nei piani a pagamento Dockup?

I piani a pagamento consentono un numero illimitato di workspace, database e deployment. Il consumo di CPU, RAM e disco utilizza comunque il saldo del piano.

Come viene misurato l'utilizzo di Dockup?

Il consumo di CPU, RAM e disco viene misurato al minuto e detratto dal saldo incluso nell'account o dal saldo ricaricato.

I prezzi basati sull'utilizzo sono sempre più convenienti di un'istanza fissa?

No. Possono far risparmiare sui workload variabili o inattivi, mentre un workload prevedibile e costantemente intenso può risultare competitivo con un'istanza fissa. Modella la stessa domanda.

Come si confrontano due prezzi PaaS?

Normalizza ore di esecuzione, CPU, memoria, disco, database, preview, trasferimento, posti e supporto; quindi identifica costi fissi, utilizzo misurato, crediti inclusi e incertezze.