Which HTTP plan to choose
Each HTTP plan defines the CPU and memory of each instance of the project. Choosing the right plan avoids two problems: paying for capacity the application never uses, or choosing a plan that is too small and watching the application take long to start, respond slowly or restart for lack of memory.
This page explains the focus of each plan and gives examples of applications that make sense on each one. Current prices appear in the console when you create the project and in the zenifra plans --type http command.
Quick summary
| Plan | vCPU | RAM | Focus | Typical examples |
|---|---|---|---|---|
| Free | 0.5 | 512 MB | Try Zenifra at no cost | First deploy, prototype, study project |
| Static | 0.1 | 64 MB | Static sites at minimum cost | Landing page, portfolio, documentation, prebuilt SPA served by NGINX |
| Basic | 0.5 | 512 MB | First dynamic application in production | Small Node.js, Python or Bun API, low-traffic Next.js site, bot |
| Premium | 1 | 1 GB | Growing applications, with metrics | API with a database, internal dashboard, n8n |
| Premium Plus | 2 | 2 GB | Heavier applications or IP-based access control | WordPress, Metabase, Django with more traffic, internal tools |
| Business | 8 | 8 GB | High traffic and CPU-intensive workloads | E-commerce, API with many concurrent users, batch processing |
| Deep Learning Basic | 4 | 4 GB + 12 GB GPU | AI inference on a GPU | Vision models, audio transcription, small LLMs |
| Deep Learning Premium | 8 | 8 GB + 24 GB GPU | Larger models on a GPU | Larger LLMs, image generation, inference that needs more VRAM |
Every paid plan offers auto-scaling: when traffic grows, Zenifra adds instances of the same plan. So, to handle more traffic, it is sometimes better to keep the plan and add instances instead of moving up a plan. See Scaling.
Free
Focus: getting to know the platform and publishing your first project at no cost.
Free has plenty of memory for a free plan (512 MB), so it runs common Node.js, Python or Bun applications. Its limits are elsewhere: the organization can have at most 1 Free instance (2 in organizations created before the free offer update), the plan has no auto-scaling and you cannot change plans from it.
- Good for: trying a repository, showing a prototype, study projects.
- Not ideal for: production. When the project gets users, recreate it on a paid plan to get auto-scaling and plan changes.
Static
Focus: putting static sites online at the lowest possible cost.
Static is Zenifra's cheapest plan and it is designed for one job: serving HTML, CSS, JavaScript and image files that are already built. With 0.1 vCPU and 64 MB per instance, it runs a lightweight HTTP server such as NGINX, Caddy or Apache serving a folder of files well.
What runs well on Static
- landing pages and company sites;
- portfolios, résumés and personal pages;
- blogs and documentation generated by tools such as Hugo, Jekyll, Astro (static mode), Docusaurus, VitePress or MkDocs, after the build;
- SPAs built with React, Vue, Angular or Svelte, already compiled and served by NGINX;
- API documentation with Swagger UI or Redoc;
- tools that run entirely in the browser, such as editors, converters and calculators.
Performance measured on the Static plan
We tested real static sites on the Static plan, with 1 instance, accessed through the project's public URL:
| Measure | Result on the Static plan |
|---|---|
| Memory used by a site served by NGINX | about 12 to 16 MB of the 64 MB |
| Server start | 2 to 7 seconds for NGINX, Caddy and Apache |
| Requests per second, with 10 concurrent visitors | 15 to 45, depending on the server and the page size |
| Typical response time (median), with 10 concurrent visitors | 200 to 300 ms for NGINX and Apache |
| Errors and restarts during the tests | none |
That comfortably serves a site with thousands of visits a day. In addition, the included CDN caches files such as JavaScript, CSS and images. As a result, most of those files reach the visitor without going through the instance, which stays free to answer the HTML. If traffic grows, enable auto-scaling before considering another plan.
What does not run well on Static
Applications built with Node.js, Python, PHP, Ruby or Java frameworks keep a process running all the time and need more memory and CPU than Static offers. In our tests, a simple Express application took more than a minute to start on Static and stayed close to its memory limit.
Static site deployed with the Node.js runtime
If your static site is deployed from a Git repository with the Node.js runtime (for example, with serve), use the Basic plan or higher. In our tests, a static site served with npx serve ran out of memory on Static and restarted before answering the first visit. To use Static, deploy an OCI image with NGINX, which serves the same files with a fraction of the memory.
- Not ideal for: APIs, server-rendered sites (Next.js, Nuxt, Remix), WordPress, applications that access a database or any running Node.js, Python or PHP process.
Basic
Focus: your first dynamic application in production.
With 0.5 vCPU and 512 MB, Basic comfortably runs a typical Node.js, Python or Bun application and supports auto-scaling.
- Good for: small REST APIs (Express, Fastify, lean NestJS, FastAPI, Flask), low-traffic Next.js sites, Discord or Telegram bots, webhooks, light workers and static sites deployed with the Node.js runtime. It also handles Jupyter Notebook for tests and light notebooks.
- Time to move up: when the application often uses memory close to the limit, when response time grows at peak hours even with auto-scaling, or when you need CPU, RAM and request metrics, available from Premium.
Premium
Focus: growing applications that need visibility.
Premium doubles Basic's CPU and memory and is the first plan with CPU, RAM, storage and HTTP request metrics, health checks and a custom subdomain.
- Good for: APIs with a database and many routes, mobile app back ends, admin dashboards, server-rendered Next.js applications and automation with n8n.
- Time to move up: when the application needs more than 1 GB per instance (BI tools, CMSs with many plugins) or IP-based access control.
Premium Plus
Focus: heavier applications and internal tools that need access control.
With 2 vCPU and 2 GB, Premium Plus runs applications that need a lot of memory right at startup. It is also the first plan with IP allowlists and blocklists, useful to restrict internal tools. See Network and access control.
- Good for: WordPress, Metabase, Django or Rails with moderate traffic, Java or .NET applications, internal dashboards reachable only from the company network.
Business
Focus: high traffic and CPU-intensive workloads on a single instance.
With 8 vCPU and 8 GB, Business is for applications already in production with many users, or that do heavy processing on each request.
- Good for: e-commerce stores with traffic spikes, APIs with many concurrent users, report and PDF generation, image or video processing, applications that keep a lot of data in memory.
Deep Learning Basic and Deep Learning Premium
Focus: AI model inference on a dedicated GPU.
| Plan | GPU | What for |
|---|---|---|
| Deep Learning Basic | NVIDIA RTX 3060 with 12 GB of VRAM | Computer vision models, audio transcription, embeddings and small LLMs |
| Deep Learning Premium | NVIDIA RTX 4090 with 24 GB of VRAM | Larger LLMs, image generation and models that need more VRAM |
Choose by VRAM: the model must fit entirely in GPU memory. If you only need to call ready-made models, without hosting your own, Zenifra AI is usually simpler.
Signs that the plan is too small
| Sign | What to do |
|---|---|
| The application takes very long to respond right after starting | Move up a plan; the available CPU cannot keep up with the startup |
| The application restarts on its own and the logs stop abruptly | Probably out of memory; move to a plan with more RAM |
| Response time grows only at peak hours | Enable auto-scaling before changing plans |
| Memory usage always close to the limit in the metrics | Move up a plan before the application starts restarting |
Plan changes are available for hourly projects and are not allowed to or from the Free plan. See Scaling.
Frequently asked questions
Can I start on Static and change later?
Yes, on hourly projects you can change the plan in Edit project. If the application stops being a static site, switch to Basic or higher.
My site is built with Next.js. Does it run on Static?
Only if you use static export (output: 'export') and serve the generated folder with NGINX. Next.js with server rendering needs a running Node.js process and should use Basic or higher. See Next.js.
More instances or a bigger plan?
More instances help when there are many concurrent visitors and each request is light. A bigger plan helps when each instance alone needs more memory or CPU, for example, to start the application or process a heavy request.
Next steps
Last updated on
Best fit for each plan
Find which Zenifra plan fits your application, Job, database, cache or queue, with the focus of each plan and examples of what runs well on it.
Which plan to choose for Scheduled Jobs
What each Zenifra Scheduled Job plan is for (job-starter, job-basic and job-premium), with examples of tasks that run well on each one.