Every hosting panel gives you MySQL and PostgreSQL. But modern applications increasingly need more than a relational database — a document store, a message queue, a search engine, an in-memory cache. Running those as Docker containers lets you add exactly the infrastructure service your app needs, right next to your websites, without a separate server or a managed cloud service. This guide covers the most common non-relational infrastructure services available as one-click templates and how to run them responsibly.
The four services most apps eventually ask for
| Service | What it is | You need it when |
|---|---|---|
| MongoDB | Document (NoSQL) database — stores flexible JSON-like documents | Your app's data does not fit neat tables, or a framework defaults to it |
| RabbitMQ | Message broker — queues work between parts of an app | You need background jobs, async processing, or services talking reliably |
| Elasticsearch | Search and analytics engine — powers fast full-text search | You need real search over lots of text, or log/analytics indexing |
| Redis | In-memory data store — cache, sessions, fast counters | You need speed: caching, session storage, rate limiting, queues |
These are the building blocks behind a great many web applications. When a project's README says "requires MongoDB" or "needs a Redis instance", this is what it means — and a container is the fastest honest way to provide it.
Why run them as containers next to your sites?
- Right-sized. A managed cloud database has a monthly floor even when idle. A container uses what it uses on a server you already pay for.
- Co-located. The service runs on the same machine as the app that uses it, so the connection is local and fast — no cross-internet latency to a managed endpoint.
- Isolated per app. Give each application its own container of a service, at the version it wants, rather than one shared instance everyone fights over.
- Disposable for development. Spin up a MongoDB or Elasticsearch to develop against, throw it away when done.
Deploying them on Panelica
Each is a one-click template from the Docker app catalog. The pattern is the same for all four:
- Deploy the service you need. The template pins a sensible version — pin it deliberately in production, because major version jumps in databases and search engines can require data migrations.
- Set authentication. Databases and brokers must not run open. Set a strong password or the service's root credentials at deploy time.
- Give it a data volume (for the stateful ones — MongoDB, Elasticsearch, RabbitMQ's durable queues). That volume is the data; protect it.
- Mind the memory, especially Elasticsearch. Elasticsearch is the heavyweight here — it wants real RAM and will struggle if starved. Redis and RabbitMQ are lighter; MongoDB sits in between. Set resource limits that match each service's appetite.
The rule that matters most: do not expose them
Infrastructure services should almost never be reachable from the internet. An open MongoDB, Elasticsearch, or Redis on a public IP is one of the most common ways data gets stolen or wiped — automated scanners find unauthenticated data stores within hours. These services are meant to be reached by your application, on the local server, not by the world.
So the reverse-proxy-a-domain pattern used for user-facing apps is exactly what you do not do here. Instead:
- Keep them on the private network. Your app connects to the service by container name over Docker's internal network. No host port needs to face the internet.
- Always require authentication even on a private network — defense in depth.
- If you truly must reach one remotely (an admin tool, a cross-server app), tunnel over SSH or restrict the port to specific IPs — never leave it open.
This is the opposite instinct from hosting a website, and it is the single most important thing to internalize about running data infrastructure.
Connecting your app
Applications deployed as containers on the same server reach these services by container name and internal port — for example, an app container connects to mongodb:27017 or redis:6379 on the shared network, with the credentials you set. If you deployed the app from a template with linked services, this wiring is done for you; if you assembled things yourself, put the app and the service on the same Docker network so name-based connection works.
Frequently asked questions
Should I use a container or a managed cloud service for production?
Containers are excellent for development, small-to-medium production loads, and keeping costs and data in-house. Managed services earn their price at large scale or when you need someone else on call for the database at 3 AM. Match the tool to the stakes.
How do I back these up?
Each stateful service has a native dump or snapshot mechanism, and an application-aware backup uses it rather than copying live data files — which for databases risks corruption. Never rely on a raw file copy of a running data store.
Can several apps share one instance?
They can, using separate databases, virtual hosts, or key prefixes depending on the service. Isolating each app in its own container is cleaner and safer when resources allow.
Why does Elasticsearch keep dying?
Almost always memory. Elasticsearch is demanding, and an undersized container gets killed by the memory limit. Give it more RAM, or reconsider whether a lighter search approach fits your needs.
The takeaway
MongoDB, RabbitMQ, Elasticsearch, and Redis are the non-relational building blocks modern apps ask for, and running them as one-click containers next to your sites is fast, cheap, and isolated. The discipline is different from hosting a website: authenticate everything, keep data volumes backed up with native dumps, size memory to each service, and — above all — keep these off the public internet. Reach them from your app on the private network, never from the world.