Reference
Plan-gated templates
Templates fall into two buckets. Anything Lofenta builds from your source, the framework starters (Next.js, Node, Astro, Bun, FastAPI, Python, Go, and friends) and plain static sites, runs on any plan including free Hobby. Templates that run a prebuilt Docker image, every managed database and every self-hosted app, are Developer plan and up. This page explains the split and the reasoning behind it.
The short version
Hobby is for building and shipping your own code for free. You get the generated framework starters and static sites on a generous slice of shared infrastructure, which is plenty for typical web apps, APIs, internal tools, and portfolios.
The moment you want Lofenta to run a prebuilt image that someone else published, a database or a self-hosted app, that moves to Developer or higher.
Two reasons. A prebuilt image can be arbitrarily heavy: a database holds a buffer pool in memory, and apps like AzuraCast or Coolify bundle their own database, queue, and proxy and idle near a gigabyte of RAM before a single visitor arrives. And paid plans allocate the dedicated CPU, RAM, and disk headroom that class of workload actually needs, instead of borrowing it from everyone else's shared Hobby capacity.
What runs on which plan
Built from your source, so the platform controls the resource envelope:
- Framework starters: Next.js, Node API, Astro, Bun, FastAPI, Python, Go, Laravel, WooCommerce, Shopify
- The Docker and Nixpacks builders (bring your own Dockerfile or auto-detect)
- Static sites
Every template that runs a prebuilt image:
- Self-hosted apps (pick from the gallery): WordPress, Ghost, Directus, Gitea, n8n, Vault, Bitwarden, Grafana, Uptime Kuma, AzuraCast, Soketi, NamelessMC, Coolify, PHP + Nginx
- Managed databases (come bundled with an app or a Compose import): PostgreSQL, MariaDB, MongoDB, Redis
New image templates auto-inherit the Developer gate, so this split stays correct as the catalog grows. The deploy wizard shows a lock badge on any template above your plan, and the same rule applies whether a database is auto-provisioned alongside an app or brought in through a Docker Compose import.
The heaviest of the heavy
A few gated templates are not just image-based, they run work continuously, regardless of whether anyone is connected. These are the ones the plan tiers are really sized for:
AzuraCast
Developer+Bundles MariaDB, Redis, Liquidsoap, Icecast, nginx, and SFTP in a single container. Idle RAM around 1 GB. Liquidsoap consumes 10 to 30 percent of a vCPU continuously while a station is on air, and per-listener bandwidth at 128 kbps means 100 listeners is roughly 12.8 Mbit/s of constant outbound. Disk grows with the music library and any stream recordings.
Coolify
Developer+A self-hosted PaaS. Auto-provisions its own PostgreSQL, Redis, and Soketi sidecars, so a single deploy is really four managed services with a combined RAM floor closer to a small VPS than a web app. See the dedicated Coolify page for how to use it on Lofenta.
n8n
Developer+Workflow automation engine. Runs scheduled and event-triggered jobs around the clock with no idle dip. Even a single recurring workflow keeps the Node.js event loop and per-workflow workers active, and memory grows with execution history.
Gitea
Developer+Self-hosted Git server. Holds an in-memory cache for the repo index, CI hooks, and auth, with sustained CPU during clones, pushes, and webhook dispatches. Light at idle but spiky under team load, so it needs the larger Developer container caps to stay responsive.
Everything else in the Developer bucket is gated for the simpler reason above: it runs a prebuilt image whose resource use Lofenta cannot bound the way it bounds a build from your source.
What you get on each plan
Plans differ on more than template access. See the pricing page for the full grid. As far as templates go:
- Hobby: framework starters and static sites, built from source. No prebuilt-image templates and no managed databases.
- Developer: everything above plus every image template, databases and self-hosted apps included, and the ability to auto-provision a database alongside an app. Container CPU and memory caps are higher across the board, so even the free starters run with more headroom.
- Team: everything above, with room to run several heavy workloads side by side without contention, plus the collaboration features.
Why gate by plan instead of a per-template surcharge?
We considered a per-service surcharge. The reason heavy templates attach to plan tiers instead is operational: a gated template needs more than a higher price. It needs a worker host with the CPU and outbound bandwidth allocated for that class of workload, monitoring that knows the normal baseline is 30 percent CPU instead of 2, and an upgrade path you can take in one click.
Plans bundle all of that. When you upgrade, your gated workloads land on infrastructure sized for them, not retrofitted around them.
Want to deploy a gated template?
Upgrade your plan from the dashboard. Existing projects keep running across the switch, only template eligibility and resource caps change at the new tier.