Best fit for each plan

Best fit for each plan

Each Zenifra plan is designed for a kind of workload. A plan that is too large costs more than it needs to; a plan that is too small makes the application slow or makes it restart for lack of memory. This section explains the focus of each plan and gives examples of applications that make sense on each one.

Choose by what you are publishing

You want to publishStart withGuide
Static site, landing page, portfolio or prebuilt SPAStaticHTTP plans
First API or dynamic site (Node.js, Python, Bun)BasicHTTP plans
Application with a database and real usersPremiumHTTP plans
WordPress, Metabase or internal toolsPremium PlusHTTP plans
Your own AI model on a GPUDeep Learning BasicHTTP plans
Task that runs on a schedulejob-starter or job-basicScheduled Jobs
Database for learning or a prototypedb-freeDatabases
Production databasedb-starter or db-basicDatabases
Session or query cachecache-starterCache and Queues
Task queue for workersqueue-starter or queue-basicCache and Queues

Three rules for choosing

  1. Start with the smallest plan that fits the application. On hourly projects, you can change the plan later in Edit project, except to or from the Free plan.
  2. Memory is the hardest limit. Too little CPU makes the application slow; too little memory makes it restart. If the application needs a language that keeps running all the time (Node.js, Python, PHP, Java), do not choose Static.
  3. More traffic does not always need a bigger plan. On paid HTTP projects, auto-scaling adds instances when traffic grows. Move up a plan when a single instance cannot keep up.

In this section

Current prices appear in the console when you create each project and in the zenifra plans command.

Last updated on

On this page