Hosting bundles explained: app, database and cache together

A bundle on RE:NODE is two or three ordinary plans - usually an app server, its database and sometimes a cache - bought in one checkout, held on one invoice and one renewal date, and cancelled together. A two-plan bundle costs 15% less than the same plans bought one by one; a three-plan bundle costs 20% less. Each server in it is a normal server with the same panel, console, files and backups as any other plan. The price of the discount is rigidity: the members renew together, cannot be upgraded on their own, and cancelling one cancels the lot. If your stack is settled and you expect to keep it for a while, a bundle is simply the cheaper way to buy it. If one piece is likely to outgrow the others soon, buy the plans separately.

That is the whole idea. The rest of this post goes through every bundle we sell, what is inside each one, what the saving is in dollars, how to wire the pieces together once they exist, and the cases where we would tell you not to bother.

What a bundle is, and what it is not#

A bundle is a billing arrangement, not a different kind of server. When you buy one, the panel creates each member server from the same code that builds a single plan, so a PostgreSQL server that arrives in a bundle is indistinguishable from one bought on its own. It has its own address and port, its own generated credentials, its own resource limits, its own backup slots and its own console. Nothing is shared between the members except the bill.

What changes is how the set is held:

• One checkout. Every server in the bundle is created after one payment. Like any other plan, they are built when payment clears, usually inside a minute.
• One invoice, one renewal date. The bundle renews as a unit. The Finances page shows it as a bundle card with a single "Renew all" button, and each member says it is part of the bundle and points you there.
• Cancelled together. Cancelling a bundle keeps every server in it running until the paid term ends, then stops them all. Cancelling a member cancels the whole bundle.
• No solo upgrades. A member server cannot be renewed, upgraded or downgraded on its own. The panel refuses it.

It is also worth being clear about what a bundle does not give you. It is not a private network between the members: the app reaches its database on the database plan's host and port, exactly as it would if you had bought them on separate days. It is not a managed service where we tune the database for your app. And it is not a different panel or a different support queue. If you already know how to run an app and a database side by side on separate plans, you already know how to run a bundle.

Every bundle we sell, with the maths#

These are the twelve bundles in the catalogue as of this post. Prices are US dollars per month on a one-month term, and they do change, so treat the bundles page on the site and the panel shop's Bundles tab as the source of truth.

The pattern is regular. Every two-plan bundle is 15% off the sum of its list prices and every three-plan bundle is 20% off. The "separately" figure is not an inflated anchor; it is just the plans' own monthly prices added up. Node.js Standard is $7 and PostgreSQL Starter is $6, so $13, and 15% off that is $11.05.

In absolute terms the savings are small - between $1.50 and $4.20 a month. Over a year that is $18 to $50, which is real money for a side project and rounding error for a business. We would rather say that plainly than dress it up: the discount is a reason to choose a bundle when it fits, not a reason to buy servers you do not need.

What each member gives you

The resources are those of the plans named above. For the common pieces:

The Java bundle is the exception that is sized up on purpose: it uses Java Advanced, with 4 GB of RAM and 1.5 vCPU, because a Spring Boot or Quarkus service on 2 GB spends its life in garbage collection. It pairs that with the 512 MB Valkey plan. The bot stack goes the other way and uses the Starter Python plan (1 GB, 0.5 vCPU), which is plenty for a bot that mostly waits on a websocket.

How the discount and payment work#

The bundle discount is applied to the monthly price, and the usual longer-term discount still applies on top. Buying a bundle for 3, 6 or 12 months gets the same term discount a single plan would, compounded with the bundle's own 15% or 20%. So the cheapest way to hold a stack you are confident about is a bundle on a 12-month term.

There are a few payment limits that catch people:

• Reward credit cannot pay for a bundle. Reward credit is tied to individual hosting lines and a bundle crosses several, so the checkout will not spend it. Your wallet balance and PayPal can.
• The crypto checkout does not take bundles yet. "Pay with crypto" works for single plans; bundles and VDS orders are not on it.
• The site's order pop-up does not take bundles. The button on the bundles page links straight to the panel shop, where bundles have their own tab.

If something goes wrong during the build - say one member fails to create while the others succeed - the bundle is still recorded as paid, the missing server is flagged to our team, and the bundle card on your Finances page says which part is missing until it is set up. You do not need to buy it again.

Which bundle fits which project#

The bundle names are fairly literal, but the fit is worth spelling out, because the wrong stack is not made right by being cheap.

Node.js + PostgreSQL, Go + PostgreSQL

The default for a typical web API or full-stack app with relational data: users, orders, anything with foreign keys and transactions. Express, Fastify, NestJS and Next.js on the Node side; a net/http or Gin service on the Go side. PostgreSQL Starter's 1 GB is enough for a database in the low gigabytes with a sensible number of connections. If you are unsure whether you want Postgres at all, Postgres or MongoDB is the longer argument.

Python + PostgreSQL + Valkey

Django, Flask or FastAPI with a relational database and a cache. Valkey earns its place here as the Celery or RQ broker, the cache backend and the session store. If your app has no background jobs and no expensive pages, you may not need the Valkey at all, in which case read when you actually need Redis before paying for one.

Node.js + MongoDB + Valkey

For a document-shaped API: content with flexible fields, event logs, anything where the schema moves weekly. Valkey handles sessions, rate limits and queues such as BullMQ. This is the shape an Express or Nest API tends to grow into after the first few months.

Java + PostgreSQL + Valkey and .NET + SQL Server

The JVM bundle is for Spring Boot, Quarkus, Micronaut or Ktor services, with the extra memory the JVM wants. The .NET bundle pairs an ASP.NET Core or Blazor app with SQL Server Express, which matters when the app was written against SQL Server and its T-SQL, and porting it to Postgres is a project in itself. Express caps each database at 10 GB, bundle or not; if you are anywhere near that, Express itself is the wrong edition.

PHP stack and Laravel stack

The PHP stack uses the plain web hosting line (HTML, CSS, JS and PHP) with MySQL 8.4 and Valkey - right for a hand-written PHP site, an older framework app, or a CMS you install yourself. The Laravel stack runs Laravel or Symfony on FrankenPHP instead, with Composer installing on start, and suits a modern Laravel app that wants Valkey for cache, sessions and queues.

WordPress + Valkey cache

One-click WordPress, which already comes with a MySQL database of its own, plus a Valkey server as a persistent object cache. This is the bundle with the most specific purpose: it helps a site with logged-in users, WooCommerce, or heavy plugins, where the same database queries run on every page. A brochure site behind full-page caching gains little from it.

Ghost + Mail Server

A Ghost publication and a Stalwart mail server of your own, so the mail Ghost sends - member sign-in links, account emails - goes out from your domain. The uncomfortable part is covered further down: Ghost's bulk newsletter sending is built around Mailgun, so a mail server of your own covers transactional mail, not mass newsletters out of the box.

Strapi + Node.js, and the bot stack

The headless bundle puts Strapi on one server for content and a Node.js server for the Next.js or Nuxt front end that reads Strapi's API. The bot stack is a Python process for a Discord or Telegram bot, a scraper or a worker, with MongoDB to keep what it collects. For the bot, picking a plan for a Discord bot covers whether Starter is enough.

Wiring the pieces together#

Once the bundle is built you have two or three servers, each with an address and port shown in the panel and credentials generated for it. The app does not find its database by magic; you give it the connection details, normally as environment variables, and keep them out of the repository. Environment variables and secrets covers why.

A typical Node.js or Python app with PostgreSQL and Valkey wants something like this, with the real hosts, ports and passwords copied from each server's page:

DATABASE_URL=postgres://app_user:GENERATED_PASSWORD@DB_HOST:DB_PORT/app_dbREDIS_URL=redis://:VALKEY_PASSWORD@VALKEY_HOST:VALKEY_PORT/0

Valkey speaks the Redis protocol, so every Redis client library - ioredis, redis-py, phpredis, Predis, Lettuce, StackExchange.Redis - connects to it with a redis:// URL as if it were Redis. For Laravel the same values go into the framework's own keys:

DB_CONNECTION=mysqlDB_HOST=MYSQL_HOSTDB_PORT=MYSQL_PORTDB_DATABASE=appDB_USERNAME=appDB_PASSWORD=GENERATED_PASSWORDREDIS_HOST=VALKEY_HOSTREDIS_PORT=VALKEY_PORTREDIS_PASSWORD=VALKEY_PASSWORDCACHE_STORE=redisSESSION_DRIVER=redisQUEUE_CONNECTION=redis

CACHE_STORE is the Laravel 11 name; older versions call it CACHE_DRIVER. Queues on Valkey also need a worker process running php artisan queue:work or Horizon, which is a long-running process of its own - plan for where it runs before you switch QUEUE_CONNECTION over. Deploying Laravel to production goes through that.

For the WordPress bundle, the usual route is the Redis Object Cache plugin with its constants in wp-config.php, added above the line that says to stop editing:

define( 'WP_REDIS_HOST', 'VALKEY_HOST' );define( 'WP_REDIS_PORT', VALKEY_PORT );define( 'WP_REDIS_PASSWORD', 'VALKEY_PASSWORD' );

Then enable the object cache from the plugin's settings page and check that it reports as connected. Valkey as a WordPress object cache covers the details and the eviction settings that stop a full cache turning into errors.

On the plain PHP web line, check phpinfo() for the redis extension before writing code against it. If it is not there, Predis is a pure-PHP client installed with Composer and needs no extension.

Ghost and its mail server

Ghost reads its mail settings from the mail block of its configuration (config.production.json in a standard install, or the equivalent mail__options__host style environment variables):

{  "mail": {    "from": "'Your Site' <noreply@example.com>",    "transport": "SMTP",    "options": {      "host": "mail.example.com",      "port": 465,      "secure": true,      "auth": { "user": "noreply@example.com", "pass": "MAILBOX_PASSWORD" }    }  }}

Before any of it lands in an inbox, the mail server needs its DNS done properly: MX, SPF, DKIM and DMARC records you add at your DNS provider, which SPF, DKIM and DMARC explained walks through. Sending works from the start; receiving mail from the internet needs port 25 forwarded, which support does on request, one mail server per address. And as above: Ghost sends bulk newsletters through Mailgun, so this setup is for sign-in links and account mail unless you change how Ghost sends newsletters.

Renewal, cancellation and changing your mind#

This is the part to read before buying, because it is where a bundle behaves differently from separate plans.

The renewal invoice for a bundle is raised once for the whole set, and the usual reminders apply: an invoice emailed 7 days before expiry and again on the day. "Renew all" renews every member to the same date. You cannot renew the database for a year and the app for a month; the term is the bundle's.

Cancelling is all or nothing. Cancel the bundle, or any member of it, and every server in it keeps running to the end of the paid term and then stops. If you want to keep the database and drop the cache, a bundle has no switch for that. Take a backup of anything you want to keep before the term ends, and download it, because deleting a server deletes its backups - locked ones included.

Upgrading one member is refused. If your PostgreSQL Starter fills up but the app is fine, there is no button to move just the database to the next tier. That is the biggest practical difference from separate plans, where upgrading a plan is a change of limits that does not rebuild the server. If you hit this, open a ticket and ask what can be done rather than cancelling in a hurry.

When to buy the plans separately#

A bundle is the right call when the stack is fixed and the sizes match. It is the wrong call in several common cases:

• One piece will grow faster than the rest. A database that will pass 20 GB in a few months, or an app that will need 4 GB once traffic arrives. Separate plans can be upgraded one at a time.
• You need a different size than the bundle uses. The bundles use set tiers. If you need PostgreSQL Standard with a Node.js Starter, there is no bundle for that, and two separate plans at the right size beat a bundle at the wrong one.
• You do not need the third piece. A three-plan bundle at 20% off is not cheaper than a two-plan purchase at list price if you never use the Valkey. The PHP stack at $8 still costs more than the $4 web plan alone.
• The app plan's own database slots are enough. Every app and web plan includes two database slots, created in the panel with a generated host, user and password. A small site or a bot with a modest table may be fine with that, and needs no separate database server at all. A database server of your own buys its own RAM, CPU, disk, root access and backup slots - worth it once the database matters, not before.
• The pieces belong to different projects or people. If the app is yours and the database is shared with another project, tying their renewal together creates a dependency you did not mean to have.
• You want to pay with reward credit or crypto. Neither works for bundles.
• You are still deciding on the stack. Running a test copy for a month before committing is cheaper than cancelling a bundle you got wrong. Staging and production on one account has more on running two copies side by side.

The way to compare is simple: price the separate plans at the sizes you actually need, then see whether a bundle matches them. If it does, take the bundle. If it is close but not quite, the separate plans win, because the cost of the wrong size is paid every day and the discount is a few dollars a month.

Backups and day-two operations#

Each member server has its own backup slots, set by its plan. The app lines and PostgreSQL and MongoDB carry 2 to 6 slots depending on tier, MySQL, SQL Server and Mail carry 1 to 4, and the small Valkey plans 0 or 1. That last one matters less than it sounds: Valkey in a bundle is a cache, sessions store or queue, and if you are treating it as a primary database you are holding it wrong. It does save to disk with AOF and snapshots, so a restart does not empty it, but the data you cannot recreate belongs in PostgreSQL, MySQL or MongoDB.

Schedule backups for the database server on its own Schedules tab, and test a restore before you need one. For a database, a dump is usually more useful than a file archive of the data directory; database backups and restores covers both and when each is safe. Beyond the backups you can see, every server is also copied by a nightly system backup outside your plan's slots; those are not on your Backups tab, and a restore from one goes through support.

Monitoring is per server. Each member has its own console and its own graphs for memory, CPU and disk against its limits, so when the app slows down, look at the database's graph too. A PostgreSQL Starter pegged at its 0.5 vCPU looks, from the app, exactly like a slow app.

FAQ#

Is a bundle server weaker than the same plan bought on its own?

No. The panel builds bundle members with the same code as single purchases, so a PostgreSQL Starter in a bundle has the same 1 GB of RAM, 20 GB of NVMe and 0.5 vCPU, and the same panel features, as one bought separately. The only differences are in billing: shared renewal date, shared cancellation, no solo upgrade.

Can I add a bundle discount to servers I already have?

No. The shop sells a bundle as a new set of servers, built from one checkout. If you already run the app and want a cache, buying a single Valkey plan is the straightforward route, and you can move data onto bundle servers later if the saving is worth the migration.

Do the bundle servers talk to each other over a private network?

No. The app connects to its database and cache on the address and port shown for each server, with the generated credentials, exactly as it would to separate plans. Keep the passwords out of your repository and use the password the panel generated rather than turning authentication off.

What happens to my data if I cancel?

The servers keep running until the end of the term you paid for, then stop. Download a backup or a database dump of anything you want before then. Once a server is deleted, its backups go with it, including any you locked against rotation.

Can I pay for a bundle for a year at a time?

Yes. Bundles take the same 3, 6 and 12-month terms as single plans, and the term discount is applied on top of the bundle's own 15% or 20%. That makes a year-long bundle the lowest monthly price for a stack you are confident in.