# deployable.sh, full catalogue facts A curated catalogue of production-shaped Docker Compose stacks (Kafka, n8n, Supabase, Keycloak, MongoDB and more), deployable in one step to Miget, or runnable locally with plain docker compose up. Pricing data as of June 2026; sources are linked on each page. ## Apache Kafka URL: https://deployable.sh/apps/kafka/ Category: Streaming & Messaging Upstream: Apache Kafka, https://kafka.apache.org Template source: https://github.com/deployable-sh/stacks/tree/main/kafka Apache Kafka is the de-facto standard event streaming platform - and one of the most expensive things to buy as a managed service. This template runs a real 3-node cluster in KRaft mode (combined broker+controller, no ZooKeeper) using the official apache/kafka image, configured entirely through environment variables. No custom images, no config files to maintain. Topic defaults are durable out of the box: replication factor 3 and min.insync.replicas=2, so a broker can die without losing acknowledged writes. Each broker keeps its log dirs on its own persistent volume. Kafbat UI ships as the public entrypoint for browsing topics, consumer groups, and messages - the brokers themselves stay private on the project network. Producers and consumers in the same Miget project connect with bootstrap servers kafka-1:9092,kafka-2:9092,kafka-3:9092 - no TLS/SASL gymnastics, the project network is the boundary. Footprint: 7 GiB RAM, 30 GB disk, 4 service(s). Miget sizing: Hobby 8 GiB plan at $49/mo; Professional 8 GiB at $85/mo. Managed-service comparison (June 2026): Confluent Cloud Basic (usage-based) ~$120/mo; AWS MSK 3× kafka.t3.small ~$130/mo. FAQ: Q: How much does it cost to self-host Kafka vs Confluent Cloud or MSK? A: This 3-broker cluster fits the 8 GiB Miget hobby plan at $49/month flat (or $85/month on a Professional plan). Managed Kafka typically starts around several hundred dollars a month for a comparable always-on 3-broker setup, before egress. The flat Miget plan also still has room for your producer/consumer apps. Q: Does this Kafka setup use ZooKeeper? A: No. The cluster runs in KRaft mode - each node is a combined broker and controller, which is the supported, ZooKeeper-free architecture in modern Kafka. Fewer moving parts, fewer pods, faster controller failover. Q: Can a broker fail without data loss? A: Yes, for acknowledged writes: topics default to replication factor 3 with min.insync.replicas=2, so the cluster tolerates one broker outage while still accepting produces with acks=all. Q: How do my applications connect to this Kafka cluster? A: Apps deployed in the same Miget project use kafka-1:9092,kafka-2:9092,kafka-3:9092 as bootstrap servers - plain PLAINTEXT on the private project network. The brokers are never exposed to the internet; only the Kafbat UI gets a public domain. Q: Can I scale this cluster to more brokers? A: Yes - add a kafka-4 service block (cluster nodes need stable identity and their own volume, so you scale by adding blocks, not replicas) and include it in the controller quorum voters list. ## Redpanda URL: https://deployable.sh/apps/redpanda/ Category: Streaming & Messaging Upstream: Redpanda, https://redpanda.com Template source: https://github.com/deployable-sh/stacks/tree/main/redpanda Redpanda speaks the Kafka API - your existing Kafka clients, libraries, and tooling work unchanged - but ships as a single C++ binary with no JVM and no ZooKeeper. The practical upshot: lower memory floors, predictable tail latency, and a much simpler ops story. This template runs three brokers (each with the Kafka API on :9092, schema registry on :8081, and HTTP proxy on :8082 built in - no extra components to deploy) plus Redpanda Console as the public web UI. Brokers seed from each other by service name and keep their data on per-node persistent volumes. Apps in the same project connect with bootstrap servers rp-1:9092,rp-2:9092,rp-3:9092. Schema registry and REST proxy come for free on every broker - things that cost extra almost everywhere else. Footprint: 6.5 GiB RAM, 30 GB disk, 4 service(s). Miget sizing: Hobby 8 GiB plan at $49/mo; Professional 8 GiB at $85/mo. Managed-service comparison (June 2026): Redpanda Cloud Serverless ~$95/mo; Confluent Cloud Basic (usage-based) ~$120/mo. FAQ: Q: Is Redpanda really compatible with Kafka clients? A: Yes - Redpanda implements the Kafka wire protocol. kafkajs, librdkafka, Spring Kafka, kcat, and the standard Kafka CLI tools all work against rp-1:9092 without code changes. Q: Why choose Redpanda over Kafka for self-hosting? A: Simplicity and footprint. No JVM tuning, no ZooKeeper, schema registry and REST proxy built in. This 3-broker Redpanda stack totals 6.5 GiB RAM where the equivalent Kafka stack needs 7 GiB - and there are four fewer things that can go wrong. Q: How much does self-hosting Redpanda cost? A: The full 3-broker cluster plus Console fits an 8 GiB Miget plan: $49/month hobby or $85/month Professional, flat. Redpanda Cloud and managed Kafka services are usage-priced and typically land far higher for an always-on 3-node cluster. Q: How do I use the schema registry? A: Every broker serves it on port 8081 - point your serializers at http://rp-1:8081 from apps in the same project. No separate schema-registry deployment needed. ## RabbitMQ URL: https://deployable.sh/apps/rabbitmq/ Category: Streaming & Messaging Upstream: RabbitMQ, https://www.rabbitmq.com Template source: https://github.com/deployable-sh/stacks/tree/main/rabbitmq RabbitMQ remains the workhorse message broker: AMQP 0-9-1, mature client libraries in every language, and (since 4.x) quorum queues as the default path to real high availability. This template runs a 3-node cluster that forms itself on first boot via classic-config peer discovery - no manual join commands. Each node keeps its state on its own persistent volume. The first node serves the management UI publicly; the other two stay private. Declare your queues as quorum queues and any single node can fail without losing messages or availability. Apps in the same project connect over AMQP at amqp://rmq-1:5672 (any node works). At 1 GiB per node, the whole HA cluster is light enough to fit a $25/month plan with room to spare. Footprint: 3 GiB RAM, 6 GB disk, 3 service(s). Miget sizing: Hobby 4 GiB plan at $25/mo; Professional 4 GiB at $43/mo. Managed-service comparison (June 2026): CloudAMQP Big Bunny (3-node HA) ~$297/mo; CloudAMQP Sassy Squirrel (1 node) ~$50/mo. FAQ: Q: How much does self-hosting RabbitMQ cost compared to CloudAMQP? A: This 3-node HA cluster fits the 4 GiB Miget hobby plan at $25/month flat. A comparable dedicated 3-node HA cluster on CloudAMQP costs an order of magnitude more; shared plans are cheaper but throttled and multi-tenant. Q: Are quorum queues enabled? A: The cluster is quorum-queue ready - declare queues with x-queue-type: quorum (or set a queue-type policy) and they replicate across all three nodes with Raft. Classic queues still work for non-critical traffic. Q: What happens if a RabbitMQ node dies? A: For quorum queues, the remaining two nodes keep a majority and the queue stays available - producers and consumers reconnect to a living node and continue. The failed node rejoins the cluster automatically when it comes back. Q: How do applications connect? A: From apps in the same Miget project: amqp://user:pass@rmq-1:5672 (any node accepts connections). For resilience, configure your client with all three hosts. AMQP is never exposed publicly - only the management UI gets a domain. ## MongoDB Replica Set URL: https://deployable.sh/apps/mongodb/ Category: Databases Upstream: MongoDB, https://www.mongodb.com Template source: https://github.com/deployable-sh/stacks/tree/main/mongodb A single MongoDB container is fine until it restarts mid-write. A replica set is the unit of production MongoDB: automatic failover, rollback safety, and the topology that change streams and transactions actually require. This template runs a 3-member replica set (rs0) on the stock mongo image - the --replSet flags ride each service’s command, no custom build. A tiny rs-init sidecar waits for the members, runs rs.initiate() exactly once (idempotent - re-runs detect the initialized set and skip), then idles at a hard 128 MiB cap. Each member keeps its data on its own 10 GB volume. Everything is internal-only by design: this template ships without auth, so the project network is the security boundary - exactly like a VPC-peered Atlas cluster, minus the bill. Apps connect with the standard multi-host connection string and get driver-level failover for free. Footprint: 3.1 GiB RAM, 30 GB disk, 4 service(s). Miget sizing: Hobby 4 GiB plan at $25/mo; Professional 8 GiB at $85/mo. Managed-service comparison (June 2026): MongoDB Atlas M10 dedicated ~$57/mo; MongoDB Atlas Flex (usage-based). FAQ: Q: How much cheaper is this than MongoDB Atlas? A: Atlas M10 - its smallest dedicated tier - runs about $57/month for one 2 GB node-equivalent cluster. This 3-member replica set fits the 4 GiB Miget hobby plan at $25/month flat, with capacity left for the apps that use it. Q: Why a replica set instead of a single mongod? A: Failover, durability, and features: multi-document transactions and change streams require a replica set. With three members, the set survives any single node failure with automatic primary election - your driver reconnects on its own. Q: How do applications connect? A: From the same Miget project: mongodb://mongo-1:27017,mongo-2:27017,mongo-3:27017/?replicaSet=rs0. Listing all members lets the driver discover the topology and fail over automatically. Q: Is it safe to run MongoDB without authentication? A: Only because nothing outside the project network can reach it: all members are private with no ingress route, the same trust model as a database inside a VPC. Never expose these services publicly; if you need cross-project access, add keyfile auth first. Q: Can I use this for transactions and change streams? A: Yes - both require a replica set, which is exactly what this is. Point your ODM (Mongoose, Prisma, Spring Data) at the rs0 connection string and they work out of the box. ## ClickHouse Cluster URL: https://deployable.sh/apps/clickhouse/ Category: Databases Upstream: ClickHouse, https://clickhouse.com Template source: https://github.com/deployable-sh/stacks/tree/main/clickhouse ClickHouse is the open-source column store that made sub-second analytics over billions of rows ordinary. This template runs a real replicated cluster - one shard, three replicas - with ClickHouse Keeper embedded in the server nodes, so there are no separate ZooKeeper or Keeper pods to deploy and feed. Tables created ON CLUSTER main with the ReplicatedMergeTree engine replicate across all three nodes; any node can take writes and queries. Each node owns a 20 GB volume, and the whole cluster is internal-only - apps in the project connect to any node over HTTP (:8123) or the native protocol (:9000). One required variable (CLICKHOUSE_PASSWORD) and you have the analytics backend that ClickHouse Cloud meters by the compute-hour - at a flat monthly price. Footprint: 6 GiB RAM, 60 GB disk, 3 service(s). Miget sizing: Hobby 8 GiB plan at $49/mo; Professional 16 GiB at $169/mo. Managed-service comparison (June 2026): ClickHouse Cloud Basic ~$67/mo; ClickHouse Cloud Scale ~$499/mo. FAQ: Q: How does this compare to ClickHouse Cloud pricing? A: ClickHouse Cloud bills compute per hour plus storage, which is excellent for spiky workloads but adds up for always-on ones. This cluster is a flat $49/month (8 GiB hobby plan) or $169/month Professional - predictable, with your data on your volumes. Q: Do I need ZooKeeper for ClickHouse replication? A: No - coordination runs on ClickHouse Keeper, embedded inside the same three server nodes. You get replicated tables with zero extra processes to operate. Q: How do I create replicated tables? A: Use CREATE TABLE ... ON CLUSTER main with ENGINE = ReplicatedMergeTree. The cluster macro config is baked in, so the standard '/clickhouse/tables/{shard}/{table}' path templates just work. Q: Can ClickHouse replace my Postgres for analytics? A: For append-heavy, aggregate-style workloads (events, logs, metrics, funnels) - emphatically yes, often 100× faster. Keep transactional row-level workloads in Postgres; ClickHouse is an OLAP engine, not an OLTP database. ## Qdrant URL: https://deployable.sh/apps/qdrant/ Category: Search & Vectors Upstream: Qdrant, https://qdrant.tech Template source: https://github.com/deployable-sh/stacks/tree/main/qdrant Qdrant is a vector database written in Rust: HNSW indexes, rich payload filtering, hybrid search, and a clean REST + gRPC API that every RAG framework (LangChain, LlamaIndex, Haystack) supports natively. If you are embedding documents and asking an LLM about them, this is the store in the middle. This template runs a single Qdrant node with a 10 GB persistent volume, internal-only by default - no API key is configured, so the project network is the security boundary. Your apps reach it at qdrant:6333 (REST) or :6334 (gRPC); nothing is exposed to the internet. Vector workloads are RAM-shaped and predictable, which makes flat-price self-hosting unusually attractive: 1 GiB holds on the order of a million 768-dim vectors with quantization to spare. Footprint: 1 GiB RAM, 10 GB disk, 1 service(s). Miget sizing: Hobby 1 GiB plan at $7/mo; Professional 2 GiB at $22/mo. Managed-service comparison (June 2026): Qdrant Cloud Standard (gpx1, 2 GiB) ~$26/mo. FAQ: Q: How much does self-hosting Qdrant cost vs Qdrant Cloud? A: This single-node template fits the 1 GiB Miget hobby plan at $7/month flat. Qdrant Cloud’s smallest always-on paid clusters land meaningfully higher for the same RAM, and egress/network policies differ - for side projects and internal RAG, flat $7 is hard to argue with. Q: Is Qdrant good for RAG applications? A: It is one of the most popular choices: native integrations in LangChain, LlamaIndex, and Haystack, payload filtering for metadata-constrained retrieval, and hybrid (dense + sparse) search for better recall. Q: Why is the template internal-only? A: It ships without an API key, so it must not face the internet. Apps in the same Miget project reach qdrant:6333 privately. To expose the dashboard, set QDRANT__SERVICE__API_KEY and remove private: true - the README walks through it. Q: How many vectors fit in this instance? A: Roughly 1M vectors at 768 dimensions in 1 GiB with defaults; with scalar quantization, several million. Bump the RAM in compose.miget.yaml and pick the next plan up as collections grow. ## ChromaDB URL: https://deployable.sh/apps/chromadb/ Category: Search & Vectors Upstream: Chroma, https://www.trychroma.com Template source: https://github.com/deployable-sh/stacks/tree/main/chromadb Chroma is the vector store most people meet first: pip install chromadb, four lines of code, and your documents are searchable by meaning. Its server mode is the same API over HTTP - which is what this template deploys, so every notebook example you have ever run keeps working against a real persistent backend. One container, one 10 GB volume, internal-only: Chroma ships without built-in auth, so the project network is the boundary (the same pattern as the MongoDB and Qdrant templates). Apps connect with chromadb.HttpClient(host="chroma", port=8000) and the JS client equivalently. For prototypes graduating to something persistent - or teams that want their embeddings off third-party infrastructure - this is the lightest possible step up. Footprint: 1 GiB RAM, 10 GB disk, 1 service(s). Miget sizing: Hobby 1 GiB plan at $7/mo; Professional 2 GiB at $22/mo. Managed-service comparison (June 2026): Chroma Cloud Starter (usage) (usage-based). FAQ: Q: How do I migrate from local Chroma to this server? A: Change chromadb.PersistentClient(path=...) to chromadb.HttpClient(host="chroma", port=8000) in apps deployed to the same Miget project. The collection API is identical; re-ingest or copy your data once. Q: Chroma Cloud vs self-hosting - when does each make sense? A: Chroma Cloud is serverless and usage-priced, great for spiky or tiny workloads. Self-hosting here is a flat $7/month (1 GiB hobby plan) with no per-query metering - predictable for always-on apps, and your embeddings stay on your infrastructure. Q: Why is there no authentication on this template? A: Chroma has no production-grade built-in auth, so the template keeps it private: no public domain, reachable only from apps in the same project. That is the correct posture - do not expose Chroma directly to the internet. Q: Is Chroma production-ready or just for prototypes? A: Single-node Chroma serves real production loads at small-to-medium scale (hundreds of thousands to low millions of vectors). If you need clustering, quantization, or heavy filtering at scale, the Qdrant template in this catalogue is the natural next step. ## Meilisearch URL: https://deployable.sh/apps/meilisearch/ Category: Search & Vectors Upstream: Meilisearch, https://www.meilisearch.com Template source: https://github.com/deployable-sh/stacks/tree/main/meilisearch Meilisearch is the open-source answer to "search that feels like Algolia": results as you type in under 50 ms, typo tolerance that just works, faceting, filtering, synonyms, and lately hybrid semantic search. It is a single Rust binary, which makes it a perfect self-hosting citizen. This template runs Meilisearch in production mode behind a master key - keyless requests are rejected - with a 5 GB volume for indexes. It is public on its app domain by design: derive scoped search keys (GET /keys) for browsers, keep the master key server-side, and you have a complete search backend. Where Algolia meters by the thousand searches and records, this is a flat $7/month for most projects. Search is the funnel feature users notice; the bill should not be. Footprint: 1 GiB RAM, 5 GB disk, 1 service(s). Miget sizing: Hobby 1 GiB plan at $7/mo; Professional 2 GiB at $22/mo. Managed-service comparison (June 2026): Meilisearch Cloud Cloud ~$20/mo; Algolia Grow (pay-as-you-go) ~$45/mo. FAQ: Q: Is Meilisearch a real Algolia alternative? A: For most product search, docs search, and app search use cases - yes. Same instant-results UX, InstantSearch-compatible libraries, typo tolerance and faceting. What you give up is Algolia’s global edge network and some enterprise analytics; what you gain is a flat price and your data on your infrastructure. Q: How much does self-hosted Meilisearch cost vs Algolia or Meilisearch Cloud? A: This template runs on the $7/month 1 GiB Miget hobby plan, flat, with no per-search or per-record metering. Algolia and Meilisearch Cloud both price by usage tiers that typically exceed that within the first serious project. Q: Is it safe that Meilisearch is publicly reachable? A: Yes, in production mode every request must carry a valid key - the master key rejects nothing-in-hand requests outright. Ship only scoped, expirable search keys to browsers; keep the master key in your backend env. Q: Does Meilisearch support semantic / AI search? A: Yes - hybrid search combines keyword relevance with vector similarity. Configure an embedder (OpenAI, Hugging Face, or REST) on an index and queries can blend both, which materially improves recall on natural-language queries. ## Supabase URL: https://deployable.sh/apps/supabase/ Category: Backend Platforms (experimental) Upstream: Supabase, https://supabase.com Template source: https://github.com/deployable-sh/stacks/tree/main/supabase Supabase is the open-source Firebase: Postgres at the core, with auth, auto-generated REST APIs, realtime subscriptions, file storage, and a polished Studio dashboard around it. The whole point of it being open source is that you can run it yourself - this template is the official self-hosting compose, adapted to deploy in one step. Only the Kong gateway is public: it fronts the APIs and serves Studio behind basic auth. Postgres runs Supabase’s own image (custom extensions and roles - deliberately not a managed database). Optional components ride compose profiles: supavisor (connection pooling), edge functions, and imgproxy enable only if you turn their profiles on. This is the largest template in the catalogue and marked experimental - validate on a dev project first. The payoff: no project pausing, no MAU pricing, no egress anxiety, and a backend that lives on your infrastructure. Footprint: 8 GiB RAM, 20 GB disk, 8 service(s). Miget sizing: Hobby 8 GiB plan at $49/mo; Professional 8 GiB at $85/mo. Managed-service comparison (June 2026): Supabase Cloud Pro ~$25/mo. FAQ: Q: Why self-host Supabase instead of using supabase.com? A: Control and cost shape: Supabase Cloud Pro is $25/month plus metered compute, egress, storage, and MAUs. Self-hosted has none of those meters - a flat plan, no project pausing, and data that never leaves your infrastructure. The trade: you operate it (updates, backups) yourself. Q: Does supabase-js work against a self-hosted instance? A: Yes - point createClient at your Kong gateway URL with the ANON_KEY you generated. Auth, PostgREST queries, realtime channels, and storage all flow through the same gateway, exactly like the hosted product. Q: What is different from the official Supabase self-hosting guide? A: Nothing structural - this is the official compose, adapted to the platform: Kong as the single public service, everything else private, profile-gated optional components, and platform overrides for RAM and volumes so it deploys in one step. Q: Why is this template marked experimental? A: It is the biggest stack in the catalogue (8-11 services) and Supabase evolves its self-hosting compose actively. It works, but validate on a dev project before trusting it with production, and expect template updates tracking upstream. Q: Can I use a managed Postgres with Supabase? A: No - Supabase requires its own Postgres image with custom extensions and roles, so this template deliberately runs the database as a container with a 20 GB volume rather than a managed service. ## Supabase Lite URL: https://deployable.sh/apps/supabase-lite/ Category: Backend Platforms Upstream: Supabase, https://supabase.com Template source: https://github.com/deployable-sh/stacks/tree/main/supabase-lite Most Supabase apps use three things: the database, auth, and the auto-generated REST API. The full self-hosted distribution ships eleven services to cover every feature - this template ships the four that carry those three workloads: supabase-postgres, GoTrue, PostgREST, and the Kong gateway in front. The payoff is footprint. The full stack wants 8-16 GiB; this core idles around 600 MiB and is sized to fit a 2 GiB plan. Studio and postgres-meta ride a compose profile - enable the dashboard when you are working on the schema, turn it off when you are not. It is the same pinned upstream images and init SQL as the full template, minus the optional surface - so supabase-js works unchanged for database, auth, and REST calls, and if you grow into Realtime or Storage later, the full template takes over with the same database volume. Footprint: 2 GiB RAM, 8 GB disk, 4 service(s). Miget sizing: Hobby 2 GiB plan at $13/mo; Professional 2 GiB at $22/mo. Managed-service comparison (June 2026): Supabase Cloud Pro ~$25/mo. FAQ: Q: What do I give up versus the full Supabase stack? A: Realtime (websocket change streams), Storage (file uploads), edge functions, the connection pooler, and image transforms. Database, auth, row-level security, and the REST/GraphQL API - the core most apps are built on - are all here. Q: Does supabase-js still work? A: Yes, for everything this stack serves: createClient against your Kong URL, then auth flows and from()/rpc() queries work unchanged. Calls to realtime channels or storage buckets will fail - those services are not running. Q: Can I upgrade to the full stack later? A: Yes - both templates use the same supabase-postgres image and init SQL, so the database volume carries over. Deploy the full supabase template pointing at your data and the extra services join around it. Q: Why is this stable when the full template is experimental? A: Four services with fixed wiring are a much smaller surface than eleven with optional profiles. The core path (db, auth, rest, kong) is boot-tested end to end and changes rarely upstream. Q: Is $13/month really cheaper than Supabase Cloud free tier? A: The cloud free tier is $0 - but it pauses projects after a week of inactivity and caps at two projects. This is for the step after: always-on, no meters, your infrastructure, still an order of magnitude less than running the full stack. ## PocketBase URL: https://deployable.sh/apps/pocketbase/ Category: Backend Platforms Upstream: PocketBase, https://pocketbase.io Template source: https://github.com/deployable-sh/stacks/tree/main/pocketbase PocketBase is the antidote to backend over-engineering: one Go binary embedding SQLite, user auth (email + OAuth2), realtime subscriptions, file storage, and a genuinely good admin dashboard. For side projects, MVPs, and a surprising number of production apps, it is all the backend there is to need. This is the simplest template in the catalogue - one service, one 2 GB volume. The admin UI lives at /_/ on your app domain; create the first superuser on first visit. SQLite and uploads persist on the volume across redeploys. SQLite is single-writer, so this scales up (more RAM, the volume grows with you), not out - keep replicas at 1. That constraint is also why it is so famously fast and simple to operate. Footprint: 512 MiB RAM, 2 GB disk, 1 service(s). Miget sizing: Hobby 512 MiB plan at $5/mo; Professional 2 GiB at $22/mo. Managed-service comparison (June 2026): Firebase Blaze (usage) (usage-based); Supabase Cloud Pro ~$25/mo. FAQ: Q: Is PocketBase production-ready? A: For small-to-medium apps, yes - it is a single Go binary on SQLite with WAL mode, and real products run on it. Its honest ceiling is write concurrency: one writer at a time. Read-heavy apps with moderate writes are its sweet spot. Q: What does PocketBase hosting cost? A: This template fits the $5/month 512 MiB Miget hobby plan - the cheapest full backend in the catalogue. Compare that with Firebase, where auth + database + storage costs scale per-use and per-MAU as you grow. Q: Why is there no required configuration? A: PocketBase bootstraps itself: deploy, open https://your-domain/_/, create the first superuser, done. Do it promptly after deploying - until a superuser exists, anyone with the URL could claim it. Q: Can PocketBase scale horizontally? A: No - SQLite is single-writer, so keep replicas at 1 and scale vertically (more RAM/CPU). If you outgrow it, the Supabase template in this catalogue is the structurally similar next step on Postgres. ## Convex URL: https://deployable.sh/apps/convex/ Category: Backend Platforms (experimental) Upstream: Convex, https://convex.dev Template source: https://github.com/deployable-sh/stacks/tree/main/convex Convex inverts the usual backend: you write TypeScript queries and mutations, and every client subscribed to a query updates automatically when its data changes - reactive end to end, with no cache invalidation code. The backend is open source, and this template runs it self-hosted with the dashboard. The topology has a quirk worth knowing: one Convex process serves two origins (the client API and HTTP actions), and each platform app publishes exactly one port - so two slim nginx proxies (api and site) front the private backend, plus the dashboard as a third public app. State lives in SQLite on a 10 GB volume. After first deploy, set CONVEX_CLOUD_ORIGIN and CONVEX_SITE_ORIGIN to the api and site apps’ https domains and redeploy - then point your Convex CLI and clients at your own deployment. Footprint: 2.8 GiB RAM, 10 GB disk, 4 service(s). Miget sizing: Hobby 4 GiB plan at $25/mo; Professional 4 GiB at $43/mo. Managed-service comparison (June 2026): Convex Cloud Professional ~$25/mo. FAQ: Q: Is self-hosted Convex the same as Convex Cloud? A: The core engine is: reactive queries, mutations, actions, scheduler, dashboard. Cloud adds multi-deployment management, preview deploys, and operational SLAs, priced per developer ($25/dev/month on Pro). Self-hosting trades those for a flat infrastructure price and full data ownership. Q: Why does this template have nginx proxies? A: Convex serves two origins (client API and HTTP actions) from one process, and each platform app exposes exactly one public port - so api and site are thin nginx apps fronting the private backend. It is wiring, not architecture. Q: How do I deploy my Convex functions to it? A: Generate an admin key (the backend image ships generate_admin_key.sh), then use the Convex CLI with CONVEX_SELF_HOSTED_URL pointing at your api domain and the admin key as credentials. The dashboard logs in with the same key. Q: Why is this marked experimental? A: The multi-origin proxy design is young and upstream self-hosting evolves quickly. It works for development and small production; validate carefully before betting a critical app on it. ## Keycloak URL: https://deployable.sh/apps/keycloak/ Category: Auth & API Gateway Upstream: Keycloak, https://www.keycloak.org Template source: https://github.com/deployable-sh/stacks/tree/main/keycloak Keycloak is the heavyweight champion of open-source identity: full OIDC and SAML, social logins, user federation (LDAP/AD), fine-grained authorization, admin console, and two decades of enterprise hardening via Red Hat. It is what you deploy when per-MAU pricing on Auth0 or Clerk stops being funny. This template runs Keycloak in production mode (start, not start-dev) backed by a managed Postgres that Miget provisions and wires automatically - host, port, credentials all injected. TLS terminates at the platform ingress with forwarded headers trusted, so issuer URLs come out as your https domain, which is exactly what OIDC clients require. All state lives in Postgres; the Keycloak pod itself is stateless and restarts clean. Two variables (bootstrap admin username/password) and you have an identity provider. Footprint: 3 GiB RAM, 5 GB disk, 2 service(s). Miget sizing: Hobby 4 GiB plan at $25/mo; Professional 4 GiB at $43/mo. Managed-service comparison (June 2026): Auth0 Essentials (B2C) ~$70/mo; Clerk Pro ~$25/mo; FusionAuth Starter (cloud) ~$162/mo. FAQ: Q: How does self-hosted Keycloak compare to Auth0 pricing? A: Auth0’s paid plans price per monthly active user and climb steeply past the entry tiers. Keycloak on this template is $25/month (4 GiB hobby plan) or $43/month Professional, flat, for unlimited users, realms, and clients. The trade is operating it yourself - which this template reduces to a deploy. Q: Is this production-mode Keycloak or a dev toy? A: Production mode: kc start with a real Postgres, proxy headers configured for the platform’s TLS ingress, and correct https issuer URLs. start-dev appears nowhere in this template. Q: Where is Keycloak’s state stored? A: Entirely in the managed Postgres (realms, users, clients, sessions config). The Keycloak pod is stateless - redeploys and restarts are uneventful, and the database gets the platform’s managed-service treatment. Q: Can I use Keycloak for SSO across my apps? A: Yes - that is its core job. Create one realm, register each app as an OIDC client, and every standard auth library (NextAuth, Spring Security, Django, Rails) points at your realm’s well-known endpoint. ## Kong Gateway URL: https://deployable.sh/apps/kong/ Category: Auth & API Gateway Upstream: Kong Gateway (OSS), https://konghq.com Template source: https://github.com/deployable-sh/stacks/tree/main/kong Kong is the most battle-tested open-source API gateway: routing, auth plugins (key, JWT, OAuth2), rate limiting, transformations, and observability hooks, all configured through a clean Admin API. This template runs DB-backed Kong OSS in front of your project’s apps. The security shape is the point: the proxy is the only public surface. The Admin API stays project-internal, and the one authenticated way in from outside is the admin service - nginx serving Kong Manager and proxying the Admin API under /api, both behind basic auth. UI and API on one origin means the Manager works with no CORS or domain configuration. On Miget, the Postgres container is never deployed - db becomes a managed Postgres and Kong’s connection settings are auto-wired from its credentials. Zero configuration at deploy time. Footprint: 2.3 GiB RAM, 5 GB disk, 3 service(s). Miget sizing: Hobby 4 GiB plan at $25/mo; Professional 4 GiB at $43/mo. Managed-service comparison (June 2026): Kong Konnect Plus (serverless gateway) ~$25/mo. FAQ: Q: Kong OSS vs Kong Konnect - what am I giving up? A: Konnect adds the hosted control plane, dev portal, and analytics, priced per service/gateway. Kong OSS here keeps the entire data plane and Admin API plus Kong Manager UI - for most teams routing internal and public APIs, that is the whole job, at a flat $25/month plan. Q: How do I configure routes and services? A: Through Kong Manager (your admin domain, basic auth) or the Admin API at /api on the same origin - or curl it from any app inside the project at kong:8001. Services point at in-project upstreams by service name, e.g. http://my-api:5000. Q: Is the Admin API safe from the internet? A: Yes - it has no public route. Outside access goes only through the nginx admin service behind basic auth; strip that service entirely and the Admin API becomes project-internal only. Q: Why DB-backed instead of declarative (DB-less) Kong? A: DB-backed enables runtime configuration through the Manager UI and Admin API without redeploys, which is the comfortable operating mode on a platform. The managed Postgres makes the usual cost of DB-backed Kong - running the database - disappear. ## GlitchTip URL: https://deployable.sh/apps/glitchtip/ Category: Error Tracking Upstream: GlitchTip, https://glitchtip.com Template source: https://github.com/deployable-sh/stacks/tree/main/glitchtip Self-hosted Sentry is famously a 20+ container leviathan (Kafka, ClickHouse, Zookeeper, an army of consumers). GlitchTip implements the Sentry API - your existing Sentry SDKs just point at a new DSN - in four lean services: web, a Celery worker, Postgres, and a Redis-compatible cache. Same SDKs, same DSN flow, a tenth of the iron. On Miget, db and queue become managed Postgres and Valkey with connection env auto-wired onto all GlitchTip services. SECRET_KEY is the only required variable. Error events, performance traces, and uptime checks land in a UI that any Sentry user will navigate without a manual. The economics are stark: error tracking SaaS meters by event volume, and one bad deploy can blow a month’s quota in an hour. Self-hosted GlitchTip ingests whatever your stack can hold - a noisy week costs disk space, not an invoice. Footprint: 3.8 GiB RAM, 5 GB disk, 5 service(s). Miget sizing: Hobby 4 GiB plan at $25/mo; Professional 4 GiB at $43/mo. Managed-service comparison (June 2026): Sentry Team ~$26/mo. FAQ: Q: Do my existing Sentry SDKs work with GlitchTip? A: Yes - GlitchTip implements the Sentry ingestion API. Swap the DSN in sentry-sdk / @sentry/node / sentry-ruby etc. and events flow. No code changes beyond the DSN. Q: GlitchTip vs self-hosted Sentry - why not real Sentry? A: Modern self-hosted Sentry needs Kafka, ClickHouse, Redis, Postgres, and dozens of containers - roughly an order of magnitude more RAM than GlitchTip’s four services. If you need Sentry’s deep tracing products, pay for sentry.io; if you need solid error tracking with the same SDKs, GlitchTip is the rational self-host. Q: What does GlitchTip cost to run vs Sentry SaaS? A: Sentry’s Team plan is ~$26/month for 50k errors, with overage pricing past quota. GlitchTip here runs $25/month flat (4 GiB hobby plan) with no event metering - a single noisy deploy stops being a billing event. Q: What is the migrate service doing in the stack? A: It runs Django migrations idempotently on every deploy and then idles. Compose platforms have no one-shot job primitive, so a tiny always-there service is the portable way to keep the schema current. ## Bugsink URL: https://deployable.sh/apps/bugsink/ Category: Error Tracking Upstream: Bugsink, https://www.bugsink.com Template source: https://github.com/deployable-sh/stacks/tree/main/bugsink Bugsink takes the minimalist position on error tracking: one container that ingests Sentry SDK events, groups them into issues, and alerts you - no Celery, no Redis, no microservices. Where GlitchTip is the lean Sentry, Bugsink is the leanest thing that still does the job properly. This template pairs that single container with a managed Postgres (auto-provisioned, DATABASE_URL auto-wired). It runs its own migrations on start. Two secrets and you are catching exceptions. Built by a Sentry-ecosystem veteran with strong opinions about software that fits in your head: synchronous ingestion, sensible defaults, and a UI focused on the only question that matters - what broke, where, how often. Footprint: 2 GiB RAM, 5 GB disk, 2 service(s). Miget sizing: Hobby 2 GiB plan at $13/mo; Professional 2 GiB at $22/mo. Managed-service comparison (June 2026): Sentry Team ~$26/mo. FAQ: Q: Bugsink or GlitchTip - which should I pick? A: Bugsink if you want the absolute minimum to operate (one container, $13-20/month plans) and primarily need error tracking. GlitchTip if you also want performance monitoring, uptime checks, and a multi-worker ingestion pipeline. Both speak Sentry SDK. Q: Does Bugsink work with my language’s Sentry SDK? A: Yes - Python, JavaScript/Node, Ruby, PHP, Go, Java, .NET, mobile: anything that emits the Sentry event protocol. Configure the SDK with your Bugsink DSN and errors arrive. Q: How much does self-hosted error tracking cost with Bugsink? A: The stack totals 2 GiB: $13/month hobby fits it exactly, $25/month gives comfortable headroom. Compare to event-metered SaaS where one crash-looping client can exhaust a monthly quota in minutes. Q: Can Bugsink handle production traffic? A: Bugsink is engineered for exactly this scale-down: synchronous ingestion with deliberate performance work upstream, comfortably handling millions of events per day on modest hardware according to its docs. For most teams, the single container is genuinely enough. ## n8n URL: https://deployable.sh/apps/n8n/ Category: Automation & Jobs Upstream: n8n, https://n8n.io Template source: https://github.com/deployable-sh/stacks/tree/main/n8n n8n is the workflow automation tool that took Zapier’s job for technical teams: 400+ integrations, a visual editor, and real code nodes when clicking runs out. Its production architecture is queue mode - the editor/webhook instance enqueues executions into Redis, and dedicated workers burn through them - and that is exactly what this template deploys. On Miget, db and queue become managed Postgres and Valkey, with connection env auto-wired onto both the main instance and the workers. One required variable (N8N_ENCRYPTION_KEY) and you have the architecture n8n’s own docs recommend for production. Workers are stateless - binary data lives in the database - so this is the one template in the catalogue where scaling replicas is the right move: bump worker replicas as workflow volume grows. n8n Cloud meters by executions; here, executions are free and the meter is your plan’s RAM. Footprint: 3.3 GiB RAM, 6 GB disk, 4 service(s). Miget sizing: Hobby 4 GiB plan at $25/mo; Professional 4 GiB at $43/mo. Managed-service comparison (June 2026): n8n Cloud Starter ~$24/mo; n8n Cloud Pro ~$60/mo. FAQ: Q: How much does self-hosted n8n cost vs n8n Cloud? A: n8n Cloud Starter is ~$24/month for 2,500 executions and Pro ~$60/month for 10,000. This stack runs ~$25/month (4 GiB hobby) with unlimited executions - the crossover happens at trivially low workflow volume, and self-hosted includes queue mode, which Cloud reserves for higher tiers. Q: What is queue mode and why does it matter? A: In default mode one process does everything - a heavy workflow blocks the editor and webhooks. Queue mode separates concerns: the main instance enqueues executions into Valkey and stateless workers execute them. It is n8n’s recommended production setup and what this template ships. Q: How do I scale n8n workers? A: Increase the n8n-worker replica count - workers are stateless (binary data lives in Postgres), so this is the one catalogue template where replicas-based scaling is correct. Each worker wants ~1 GiB. Q: Are community nodes and AI features available self-hosted? A: Yes - community nodes install from the editor, and the AI/LangChain agent nodes work with your own API keys. Self-hosted n8n has no feature meter on executions or workflows. Q: What happens if I lose N8N_ENCRYPTION_KEY? A: Stored credentials become undecryptable - workflows survive but every connection must be re-authenticated. Treat the key like a database backup: store it in a password manager the day you deploy. ## Cronicle URL: https://deployable.sh/apps/cronicle/ Category: Automation & Jobs Upstream: Cronicle, https://github.com/jhuckaby/Cronicle Template source: https://github.com/deployable-sh/stacks/tree/main/cronicle Every team has the crontab nobody remembers writing, on the server nobody dares reboot. Cronicle replaces it with something visible: a web UI where jobs have schedules, logs, run history, timelines, retries, chaining, and alerts when things fail - the operational basics crontab never had. This template runs single-server Cronicle in one container with two small volumes (job data and logs). No required variables - but the UI is public and ships with admin/admin, so changing that password is step one after deploy. Jobs run inside the container via shell or HTTP plugins: apk add what your scripts need, or - the more platform-native pattern - use HTTP jobs to poke endpoints on your other apps in the project, turning Cronicle into the scheduler for your whole stack. Footprint: 512 MiB RAM, 2 GB disk, 1 service(s). Miget sizing: Hobby 512 MiB plan at $5/mo; Professional 2 GiB at $22/mo. Managed-service comparison (June 2026): Cronitor Business (pay-as-you-go) ~$20/mo; Healthchecks.io Business ~$20/mo. FAQ: Q: Why Cronicle instead of plain cron or platform cronjobs? A: Visibility and operations: run history, output logs, failure alerts, retries, and chaining in a UI anyone on the team can read. Platform-native cronjobs are great for app-internal tasks; Cronicle shines as the central, observable scheduler across many services. Q: How do jobs interact with my other applications? A: Two patterns: HTTP plugin jobs that call endpoints on other apps in the project by service name (recommended), or shell jobs inside the Cronicle container - apk add your tooling in a derived image if scripts need more than busybox. Q: Is the default login really admin/admin? A: Yes - and the UI is public on your app domain, so change it immediately after first deploy (Admin → Users). Treat that as part of the deploy checklist, not a someday task. Q: Can Cronicle run distributed across multiple servers? A: Upstream Cronicle supports multi-server clusters, but this template deliberately runs single-server mode - keep replicas at 1. For one scheduler coordinating HTTP jobs, that is the right shape. ## MinIO URL: https://deployable.sh/apps/minio/ Category: Object Storage Upstream: MinIO, https://min.io Template source: https://github.com/deployable-sh/stacks/tree/main/minio MinIO is the reference implementation of "S3, but yours": the full S3 API - presigned URLs, multipart uploads, versioning, lifecycle (ILM) rules, bucket notifications - in a single Go binary. Every S3 SDK and tool works against it unchanged. This template runs a single node with a 20 GB volume and the web console as the public entrypoint. Root credentials come from two required variables; create scoped access keys in the console for each app. In-project apps hit http://minio:9000 with path-style addressing - object storage with zero egress fees and LAN latency to your compute. Worth knowing: Miget has native managed Buckets, which are the lower-ops choice for plain storage. Deploy MinIO when you specifically want MinIO - S3 event hooks driving workflows, ILM rules, or self-managed everything. Footprint: 1 GiB RAM, 20 GB disk, 1 service(s). Miget sizing: Hobby 1 GiB plan at $7/mo; Professional 4 GiB at $43/mo. Managed-service comparison (June 2026): AWS S3 pay-as-you-go (usage-based); Cloudflare R2 pay-as-you-go (usage-based). FAQ: Q: When should I use MinIO instead of AWS S3 or R2? A: When your compute lives next to it: zero egress fees, sub-millisecond latency, and no external dependency for dev/staging/internal apps. S3/R2 still win for global distribution and eleven-nines durability - single-node MinIO is one volume, so back up what matters. Q: Do existing S3 SDKs and tools work? A: Yes - set the endpoint to http://minio:9000, use path-style addressing, and boto3, the AWS CLI, rclone, and every S3 client behave normally. Presigned URLs work for browser uploads too. Q: Should I use this or Miget’s native Buckets? A: Native Buckets for plain managed storage - less to operate. This template is for MinIO-specific powers: S3 event notifications driving workers, ILM rules, versioning policies, or compliance reasons to self-manage the storage layer. Q: Can MinIO scale beyond one node? A: Upstream MinIO does (distributed mode, 4+ nodes, erasure coding) and a cluster variant is on this catalogue’s roadmap. This template is deliberately single-node - the right shape for app storage measured in gigabytes, not petabytes. ## Agent Box URL: https://deployable.sh/apps/agent-box/ Category: AI Agents Upstream: Claude Code + opencode + Kilo CLI, https://docs.anthropic.com/en/docs/claude-code Template source: https://github.com/deployable-sh/stacks/tree/main/agent-box Coding agents got good enough that the bottleneck moved: your laptop has to stay open while they work. Agent Box moves the agent to the platform - a persistent container with Claude Code, opencode, and Kilo CLI preinstalled, reachable from any browser as a web terminal (ttyd + tmux) behind basic auth. The workflow it unlocks: kick off a long agent run from a laptop or phone, close the tab, and reattach later - the tmux session keeps running server-side, and the 10 GB /workspace volume survives redeploys. Clone your repos once; your agents and their context live there. Two variables - TTYD_PASSWORD for the terminal and ANTHROPIC_API_KEY for the agents (billed to you) - and you have a development box that never sleeps. Footprint: 2 GiB RAM, 10 GB disk, 1 service(s). Miget sizing: Hobby 2 GiB plan at $13/mo; Professional 2 GiB at $22/mo. FAQ: Q: Why run Claude Code on a server instead of my laptop? A: Long runs survive sleep, network drops, and closed lids. The tmux session keeps executing while you are away, and reattaching from any device shows you what happened - agent time stops being coupled to laptop-open time. Q: Is it safe to expose a terminal to the internet? A: The terminal sits behind basic auth over HTTPS, and the API key lives only in server env. Use a long random TTYD_PASSWORD and treat the box like any dev machine: real credentials only where needed, and remember the agents inside can run arbitrary commands - that is the point. Q: How do I reattach to a running agent session? A: Open the app URL, authenticate, and you land back in tmux - the session never ended. From a second device the same applies; tmux multiplexes happily. Q: What does it cost to run? A: The box itself is $13/month (2 GiB hobby plan). The real cost is API usage by the agents, billed to your Anthropic key - the box just keeps them running while your laptop does not have to. ## OpenClaw URL: https://deployable.sh/apps/openclaw/ Category: AI Agents Upstream: OpenClaw, https://openclaw.ai Template source: https://github.com/deployable-sh/stacks/tree/main/openclaw OpenClaw is an autonomous agent designed to live on a server, not in a chat tab: it has a dashboard, scheduled tasks, a plugin system, and a persistent workspace where its files and context accumulate. Think of it as hiring an agent and giving it a desk. This template runs the coollabsio all-in-one image (nginx + gateway, env-driven) with a 5 GB /data volume. Three secrets configure it: your Anthropic API key, a dashboard password, and a gateway token; after first deploy you pin OPENCLAW_ALLOWED_ORIGINS to your https domain. Treat it as a privileged deployment - an autonomous agent with an API budget and a persistent disk. Give it its own API key with a spending limit, and read its task history the way you would review a new hire’s work. Footprint: 2 GiB RAM, 5 GB disk, 1 service(s). Miget sizing: Hobby 2 GiB plan at $13/mo; Professional 2 GiB at $22/mo. FAQ: Q: What can OpenClaw actually do autonomously? A: Whatever its tasks and plugins allow: recurring research, monitoring and summarizing, file processing in its workspace, calling external APIs. You define tasks in the dashboard; it executes on schedule and keeps history you can audit. Q: Why does the template call this a privileged deployment? A: Because it is an autonomous agent with your API key and a persistent disk. Scope the key, set a billing limit, use a strong dashboard password, and lock OPENCLAW_ALLOWED_ORIGINS to your domain - the standard posture for anything that acts on its own. Q: What does running OpenClaw cost? A: Infrastructure is $13/month (2 GiB hobby plan). Model usage on your Anthropic key dominates real cost and scales with how busy you keep the agent - a spending limit on the key keeps surprises out. Q: Does the agent’s memory survive redeploys? A: Yes - state and workspace live on the /data volume. Redeploying the image (updates, config changes) leaves the agent’s accumulated context intact. ## Hermes Agent URL: https://deployable.sh/apps/hermes/ Category: AI Agents (experimental) Upstream: Hermes Agent (Nous Research), https://hermes-agent.nousresearch.com Template source: https://github.com/deployable-sh/stacks/tree/main/hermes Hermes Agent is Nous Research’s take on agents that get better at your tasks: a learning loop distills successful sessions into reusable skills, so the agent you run in month two is measurably more capable at your workflows than the one you deployed. Plus the practical machinery - cron, hooks, a web dashboard. This template runs the official image as a single container with a 5 GB /opt/data volume where everything persistent lives: sessions, memories, learned skills, and config. The dashboard sits behind basic auth on your domain; the gateway API stays project-internal unless you opt in. Like every agent in this catalogue: treat it as a privileged deployment. It runs on your Anthropic API key with a persistent memory - scope the key, cap the spend, and enjoy having an employee who files their own learnings. Footprint: 2 GiB RAM, 5 GB disk, 1 service(s). Miget sizing: Hobby 2 GiB plan at $13/mo; Professional 2 GiB at $22/mo. FAQ: Q: What makes Hermes different from other self-hosted agents? A: The learning loop: it reviews its own successful sessions and distills them into skills it applies to future tasks. Most agents start from zero every session; Hermes is designed to compound. Q: Why is this template marked experimental? A: Hermes Agent’s deployment shape is still stabilizing upstream - image layout and config evolve. The template tracks it, but expect occasional breaking updates; pin versions for anything you rely on. Q: Can other apps call Hermes programmatically? A: Yes - enable the gateway API with API_SERVER_ENABLED=true and an API_SERVER_KEY. It listens project-internally on hermes:8642, so other apps in the project can submit tasks without anything public. Q: What does the agent remember between restarts? A: Everything that matters: sessions, memories, learned skills, and configuration persist on the /opt/data volume across redeploys and restarts. ## Kilo (headless) URL: https://deployable.sh/apps/kilo/ Category: AI Agents (experimental) Upstream: Kilo, https://kilo.ai Template source: https://github.com/deployable-sh/stacks/tree/main/kilo Kilo is an open-source AI coding agent; kilo serve is its headless mode - an HTTP+SSE API that Kilo clients attach to. Run it on a platform and the agent outlives your editor: the IDE extension, kilo attach from a terminal, or the Cloud Agents web UI (via Remote Connections) all connect to the same persistent brain. This template runs server mode behind HTTP basic auth with a 10 GB /workspace volume that survives redeploys. Clone your repos into the workspace once; every client that attaches sees the same state. Two variables: KILO_SERVER_PASSWORD for the API and ANTHROPIC_API_KEY (or configure another provider through Kilo’s config in the workspace). Prefer a terminal over an API? The agent-box template ships the Kilo CLI alongside Claude Code and opencode in a browser terminal. Footprint: 2 GiB RAM, 10 GB disk, 1 service(s). Miget sizing: Hobby 2 GiB plan at $13/mo; Professional 2 GiB at $22/mo. FAQ: Q: What is the difference between Kilo and agent-box? A: Interface. This template exposes Kilo’s server API for programmatic and IDE clients; agent-box gives you a browser terminal with the Kilo CLI (plus Claude Code and opencode) inside. Same agent family, API versus terminal. Q: How do I connect my IDE to it? A: Point the Kilo extension (or kilo attach) at https://your-app-domain with KILO_SERVER_PASSWORD as the basic-auth credential. The Cloud Agents web UI connects the same way via Remote Connections. Q: Why run Kilo remotely instead of locally? A: Persistence and reach: long tasks keep running after your editor closes, the workspace state is shared by every client you attach from, and a phone or tablet can check on (or redirect) the agent mid-task. Q: Why is this marked experimental? A: Kilo’s server mode and remote-connection protocol are young and moving fast upstream. It works today; expect the template to track breaking changes. Pin image versions for stability. ## Appsmith URL: https://deployable.sh/apps/appsmith/ Category: Internal Tools Upstream: Appsmith CE, https://www.appsmith.com Template source: https://github.com/deployable-sh/stacks/tree/main/appsmith Every team eventually needs the same internal apps - a support dashboard, a refund tool, an ops panel over the production database. Appsmith is the open-source way to build them in hours: drag widgets onto a canvas, connect Postgres/MySQL/Mongo/REST/GraphQL datasources, and write JavaScript anywhere logic is needed. This template runs the Appsmith CE all-in-one image - embedded MongoDB, Redis, and Postgres in one container - behind a thin nginx proxy with websocket passthrough (the image serves on :80 and the platform publishes :5000, so the proxy bridges the two). State persists on the /appsmith-stacks volume. The economics are the point: internal-tool SaaS prices per seat, and internal tools by definition have many viewers. Self-hosted Appsmith CE has unlimited builders and users; the only thing that scales is how good your tools get. Footprint: 4 GiB RAM, 5 GB disk, 2 service(s). Miget sizing: Hobby 4 GiB plan at $25/mo; Professional 4 GiB at $43/mo. Managed-service comparison (June 2026): Retool Team ~$150/mo; Appsmith Cloud Business ~$375/mo. FAQ: Q: How does self-hosted Appsmith compare to Retool pricing? A: Retool Team runs ~$150/month for a small team (5 builders + 20 end users, billed annually) and grows with every seat. This stack is $49/month flat with unlimited users - the crossover happens at roughly two users, and internal tools always grow viewers. Q: Why is there an nginx proxy in the stack? A: The Appsmith image serves on port 80 with no env to change it, and the platform publishes port 5000. The proxy bridges that and passes websockets through (Appsmith realtime runs over Socket.IO). It adds 128 MiB and zero operational surface. Q: Is the embedded MongoDB fine for production? A: For typical internal-tool workloads, yes - it is Appsmith’s default deployment shape, and everything persists on the volume. At larger scale, point APPSMITH_DB_URL at an external MongoDB replica set (5.0+, readWrite + clusterMonitor roles) - this catalogue’s mongodb template is exactly that. Q: Can my whole team use it without extra cost? A: Yes - Appsmith CE has no seat limits. After the first admin signs up, registration is invite-only by default; invite builders and viewers freely. Paid Appsmith plans add SSO, granular roles, and audit logs, not seats. Q: What datasources can I connect from inside the project? A: Anything reachable on the project network by service name - the catalogue’s Postgres-backed stacks, mongodb, clickhouse, or any API your apps expose - plus external databases and REST/GraphQL endpoints over the internet. ## ToolJet URL: https://deployable.sh/apps/tooljet/ Category: Internal Tools Upstream: ToolJet CE, https://www.tooljet.ai Template source: https://github.com/deployable-sh/stacks/tree/main/tooljet ToolJet is the modern entry in the internal-tools race: a visual app builder with 50+ datasource connectors, JavaScript and Python in queries, workflow automation, and a built-in spreadsheet-style database (PostgREST-backed) for when you have no datasource at all yet. This is the cleanest deployment in the Internal Tools category: the ToolJet server respects PORT, so it listens on :5000 directly - no proxy - and all state lives in Postgres, which Miget provisions as a managed service and auto-wires. The app container itself is stateless. Three generated secrets and you are building. ToolJet Cloud caps the free and Pro tiers by apps and end users; CE self-hosted has neither cap, which is exactly the property you want in a tool whose whole job is to multiply across your org. Footprint: 3.5 GiB RAM, 6 GB disk, 2 service(s). Miget sizing: Hobby 4 GiB plan at $25/mo; Professional 4 GiB at $43/mo. Managed-service comparison (June 2026): Retool Team ~$150/mo; ToolJet Cloud Pro ~$79/mo. FAQ: Q: How does self-hosted ToolJet compare to ToolJet Cloud and Retool? A: ToolJet Cloud Pro is $79/month flat but caps you at 5 apps and 100 end users; Retool Team lands ~$150/month for a small team and grows per seat. This stack is $25/month flat with no app or user caps - CE gates enterprise features (SSO, audit logs), not scale. Q: What is the ToolJet Database and do I need to set anything up? A: A built-in, spreadsheet-style data store backed by PostgREST (bundled in the image). It uses its own database (tooljet_db) on the same Postgres server, created automatically on first boot - you just provide PGRST_JWT_SECRET. Q: Where does ToolJet store its state? A: Entirely in Postgres - apps, queries, users, encrypted datasource credentials. The container is stateless and needs no volume, so redeploys are clean and the managed database carries the persistence story. Q: What happens if I lose LOCKBOX_MASTER_KEY? A: Saved datasource credentials become undecryptable and must be re-entered. Apps and queries survive. Store the key in a password manager the day you generate it, same discipline as n8n’s encryption key. ## Budibase URL: https://deployable.sh/apps/budibase/ Category: Internal Tools Upstream: Budibase, https://budibase.com Template source: https://github.com/deployable-sh/stacks/tree/main/budibase Budibase leans into the forms-and-workflows end of internal tooling: CRUD apps over a built-in database, public forms, approval chains, and automations - the kind of thing ops and back-office teams ask for weekly. Less code-centric than Appsmith or ToolJet, faster to something shippable. This template runs the all-in-one image (embedded CouchDB, Redis, MinIO, app server and worker) behind a thin websocket-aware nginx proxy. It is the lowest-friction deploy in the category: no required variables at all - secrets auto-generate on first boot and persist in a .env on the /data volume. Self-hosted, the open-source core has unlimited creators and users; Budibase’s paid tiers gate SSO and branding, not seats. Compare that with the cloud math, where a 5-creator team lands at ~$349/month. Footprint: 4 GiB RAM, 10 GB disk, 2 service(s). Miget sizing: Hobby 4 GiB plan at $25/mo; Professional 4 GiB at $43/mo. Managed-service comparison (June 2026): Retool Team ~$150/mo; Budibase Cloud Premium ~$349/mo. FAQ: Q: Budibase, Appsmith, or ToolJet - which one? A: Budibase for forms, CRUD, and approval workflows with the least setup; Appsmith for code-heavy admin panels over many datasources; ToolJet for the middle ground with the cleanest deployment (stateless app + managed Postgres). All three are in this catalogue - deploying two and comparing costs less than a Retool seat. Q: Really no required configuration? A: Really - JWT secret, MinIO keys, and CouchDB credentials auto-generate on first boot and persist in a .env file on the /data volume, so they survive redeploys. Create the first admin account promptly; until then the instance is claimable by whoever visits. Q: How does self-hosting compare to Budibase Cloud pricing? A: Budibase Cloud Premium works out to ~$349/month for 5 creators + 20 end users ($49 base + $50 per extra creator + $5 per end user). This stack is $49/month flat with unlimited seats - the paid tiers gate SSO and branding, not capacity. Q: What is in the /data volume? A: Everything: CouchDB documents (apps, tables, users), uploaded files in the embedded MinIO, and the generated secrets. Back up that one volume and you can rebuild the instance anywhere. ## TimescaleDB URL: https://deployable.sh/apps/timescaledb/ Category: Databases Upstream: TimescaleDB, https://github.com/timescale/timescaledb Template source: https://github.com/deployable-sh/stacks/tree/main/timescaledb Time-series data has a way of arriving: metrics, sensor readings, prices, events. TimescaleDB is the answer for teams who want it in Postgres - real SQL, joins against business tables, every Postgres driver and ORM - with the time-series machinery (partitioning, compression, downsampling) handled by the extension. Hypertables auto-partition by time behind a normal table interface. Columnar compression routinely cuts metrics-shaped data by 90%+. Continuous aggregates keep rollups (per-minute, per-hour) incrementally up to date so dashboards stop re-scanning raw data. This template runs a single node with the extension preloaded, internal-only - databases never get a public domain - with a 20 GB volume. It exists precisely because managed Postgres offerings (Miget’s included) do not ship the timescaledb extension. One password and your apps connect at timescaledb:5432. Footprint: 2 GiB RAM, 20 GB disk, 1 service(s). Miget sizing: Hobby 2 GiB plan at $13/mo; Professional 4 GiB at $43/mo. Managed-service comparison (June 2026): Tiger Cloud Performance ~$30/mo; InfluxDB Cloud Serverless (usage) (usage-based). FAQ: Q: Why not just use the managed Postgres for time series? A: You can, until the data grows: vanilla Postgres lacks automatic time partitioning, columnar compression, and incremental rollups, so tables bloat and dashboards slow down. The timescaledb extension is not available in managed Postgres offerings, which is exactly why this template exists. Q: How does this compare to Timescale (Tiger) Cloud pricing? A: Managed Timescale prices compute per hour plus storage, which is excellent for elastic workloads and adds up for always-on ones. This node is $13/month flat (2 GiB hobby plan) - and your metrics never leave your project network. Q: Is TimescaleDB a real InfluxDB alternative? A: For most workloads, yes - with the advantage that it is plain SQL in Postgres: joins against your business data, standard drivers, no new query language. InfluxDB still has an edge in ultra-high-cardinality edge collection; for app and infra metrics, hypertables win on ergonomics. Q: How do applications connect? A: From the same Miget project: postgres://app:@timescaledb:5432/app - any Postgres client works. The node is private with no ingress route; if you need external access, tunnel through your apps rather than exposing the database. Q: How much data fits in 20 GB? A: With compression, typically hundreds of millions of metric rows. Add a retention policy (drop_chunks) for raw data you only need recently, keep continuous aggregates forever - the volume can be resized when you genuinely outgrow it. ## Uptime Kuma URL: https://deployable.sh/apps/uptime-kuma/ Category: Monitoring & Analytics Upstream: Uptime Kuma, https://github.com/louislam/uptime-kuma Template source: https://github.com/deployable-sh/stacks/tree/main/uptime-kuma Uptime Kuma is one of the most loved projects in self-hosting, and for a reason: it does one job - is my stuff up? - with a beautiful UI, sub-minute checks, and alerting to practically everything (Slack, Telegram, Discord, email, webhooks, PagerDuty, 100+ providers). Public status pages included. This template runs v2 (the slim image: no embedded Chromium or MariaDB) with SQLite on a small volume - one 512 MiB container that comfortably watches everything you run. Monitors, history, and settings persist across redeploys; the first-boot wizard creates your admin account. Hosted monitoring meters by monitor count - 10 here, 50 there, each tier a new invoice line. Kuma monitors as much as you like for the price of the container it runs in. Footprint: 512 MiB RAM, 2 GB disk, 1 service(s). Miget sizing: Hobby 512 MiB plan at $5/mo; Professional 2 GiB at $22/mo. Managed-service comparison (June 2026): UptimeRobot Solo ~$8/mo; Better Stack Uptime (usage) ~$25/mo; Pingdom Synthetics entry ~$10/mo. FAQ: Q: How does this compare to UptimeRobot or Better Stack pricing? A: UptimeRobot Solo is $8/month for 10 monitors; Better Stack adds $25/month per 50 monitors. Uptime Kuma on the $5/month plan has no monitor count at all - and the status pages, multi-location-style checks, and SMS-grade alerting (via your providers) come with it. Q: Can Uptime Kuma monitor my other apps in the same project? A: Yes, two ways: over their public domains (the real user-facing check), or privately by service name (http://my-api:5000/health) for internal services that have no public ingress - something hosted monitors physically cannot do. Q: What is different in Uptime Kuma v2? A: v2 is the current stable line (2.x since early 2026): a first-boot setup wizard, optional MariaDB backend, better performance at high monitor counts. This template uses the slim image with SQLite, which is the right default for almost everyone. Q: Does it work behind the platform ingress? A: Yes - the UI runs over websockets, which the ingress passes through, and the app gets its own domain (Kuma does not support subpath hosting, so a dedicated domain is exactly the right shape). Turn on "Trust Proxy" in Settings for correct client IPs. ## Umami URL: https://deployable.sh/apps/umami/ Category: Monitoring & Analytics Upstream: Umami, https://umami.is Template source: https://github.com/deployable-sh/stacks/tree/main/umami Google Analytics became a compliance question; the answer for most sites is privacy-first analytics: no cookies, no cross-site tracking, no consent banner needed, and a dashboard that shows what you actually check - visitors, referrers, pages, countries, events. Umami is the open-source standard of that category. This template runs Umami v3 (PostgreSQL-only since v3) as one stateless container on a managed Postgres that Miget provisions and auto-wires. One secret (APP_SECRET), a default admin/umami login to change on first visit, and a ~2 KB script tag for your sites. Hosted privacy analytics price per pageview tier and per site. Self-hosted Umami has neither meter: track every site you own, keep the data on your infrastructure, and let the database be the only thing that grows. Footprint: 1.5 GiB RAM, 5 GB disk, 2 service(s). Miget sizing: Hobby 2 GiB plan at $13/mo; Professional 2 GiB at $22/mo. Managed-service comparison (June 2026): Plausible Starter ~$9/mo; Fathom entry ~$15/mo; Umami Cloud paid ~$20/mo. FAQ: Q: How does self-hosted Umami compare to Plausible or Fathom pricing? A: Plausible starts at $9/month for one site and 10k pageviews; Fathom at $15/month for 100k; Umami Cloud at $20/month for 1M events. This stack is $13/month flat with no site, pageview, or event caps - and the visitor data never leaves your infrastructure. Q: Do I still need a cookie consent banner? A: Not for Umami itself - it sets no cookies and stores no personal identifiers, which is the design goal of privacy-first analytics. (Your other scripts may still need consent; Umami stops being the reason.) Q: How do I add a website? A: Log in, add the site in the dashboard, and paste the generated script tag - https://your-domain/script.js with your website id - into your pages. Data appears in realtime; UTM parameters and custom events work out of the box. Q: Can it handle real traffic volumes? A: Yes - the collection endpoint is a lightweight Next.js API writing to Postgres, and a 1 GiB managed instance absorbs millions of monthly pageviews. Past that, scale the database plan before the app. Q: Why is Umami v3 Postgres-only? A: Upstream dropped MySQL in v3.0 to focus the schema and migrations on one engine. Convenient here: the managed Postgres is exactly what it wants, auto-provisioned and auto-wired. ## Vaultwarden URL: https://deployable.sh/apps/vaultwarden/ Category: Security Upstream: Vaultwarden, https://github.com/dani-garcia/vaultwarden Template source: https://github.com/deployable-sh/stacks/tree/main/vaultwarden Vaultwarden reimplements the Bitwarden server API in Rust - so the polished official clients (browser extensions, iOS/Android apps, desktop, CLI) connect to your server unchanged, while the server itself shrinks from Bitwarden’s multi-container official stack to one binary idling at a few dozen megabytes. Features that are paid tiers on bitwarden.com - TOTP authenticator, file attachments, emergency access, organizations with collections - are simply included. SQLite, attachments, and keys live on one small volume; websocket notifications ride the main port. Passwords are the one workload where self-hosting is also a sovereignty statement: the encrypted vaults sit on your volume, end-to-end encrypted by the clients, and the hardening path (close signups, hash the admin token, back up the volume) is three steps in the README. Footprint: 256 MiB RAM, 2 GB disk, 1 service(s). Miget sizing: Hobby 512 MiB plan at $5/mo; Professional 2 GiB at $22/mo. Managed-service comparison (June 2026): Bitwarden Teams ~$40/mo; 1Password Business ~$80/mo. FAQ: Q: Do the official Bitwarden apps really work with it? A: Yes - set your server URL to your Vaultwarden domain in any official Bitwarden client and log in. The API compatibility is the whole project; millions of users run exactly this setup. Q: How does the cost compare to Bitwarden or 1Password for a team? A: Bitwarden Teams is $4/user/month ($40 for ten people), 1Password Business about $80 for ten. Vaultwarden is $5/month flat regardless of team size, with the premium features included. The trade: you operate and back it up. Q: Is self-hosting passwords safe? A: The encryption model helps you: vaults are end-to-end encrypted by the clients, so the server only ever stores ciphertext. Your responsibilities are availability and backups - keep HTTPS on (the platform ingress does), close signups after onboarding, hash the admin token, and back up the volume. Q: What happens if my server is down - am I locked out? A: No. Bitwarden clients cache the encrypted vault locally, so reading credentials keeps working offline; you only need the server up to sync changes and onboard new devices. ## Langfuse URL: https://deployable.sh/apps/langfuse/ Category: LLM Infrastructure Upstream: Langfuse, https://langfuse.com Template source: https://github.com/deployable-sh/stacks/tree/main/langfuse The moment agents ship, tracing volume explodes: every LLM call, tool invocation, and retry becomes a span you want to see when something goes weird. Langfuse is the open-source standard for that - traces, evaluations, prompt management, cost and latency dashboards - with SDKs and OpenTelemetry support across every framework. This template mirrors the official v3 self-host topology: web and worker on a managed Postgres, single-node ClickHouse for the analytics volume (CLICKHOUSE_CLUSTER_ENABLED=false, no Keeper), a Valkey wrapper pinned to maxmemory-policy=noeviction (Langfuse queues jobs there - eviction would lose events), and a MinIO blob store with the bucket pre-created. Hosted LLM observability meters by the unit - and a busy agent emits thousands per hour. Self-hosted Langfuse meters nothing; ClickHouse compression eats traces for breakfast, and the catalogue’s sizing gives it room to. Footprint: 7 GiB RAM, 35 GB disk, 6 service(s). Miget sizing: Hobby 8 GiB plan at $49/mo; Professional 8 GiB at $85/mo. Managed-service comparison (June 2026): Langfuse Cloud Core ~$29/mo; LangSmith Plus ~$39/mo. FAQ: Q: How does self-hosting compare to Langfuse Cloud pricing? A: Langfuse Cloud Core is $29/month for 100k tracing units with graduated overage from $8 per 100k - and agentic apps burn units fast, since every span counts. This stack is $49/month flat at any volume; the crossover for a team running agents in production arrives within weeks. Q: Is self-hosted Langfuse the full product? A: The core platform - tracing, evals, datasets, prompt management, dashboards - is MIT-licensed and fully included. A few enterprise features (SSO enforcement, audit logs) sit behind a commercial license, same as the cloud tiers gate them. Q: Why does the stack need six services? A: It mirrors the official v3 architecture: Postgres for transactional state, ClickHouse for the analytical trace volume, a queue (Valkey) between API and worker so ingestion never blocks, and S3 (MinIO) for raw event and media payloads. The template wires all of it - you deploy one stack. Q: How do my apps send traces to it? A: Point the Langfuse SDK (or OpenTelemetry exporter) at your web app domain with keys from project settings. Apps inside the same Miget project can use http://web:5000 and skip the public hop entirely. Q: Does single-node ClickHouse limit me? A: Not until serious scale - single-node handles hundreds of millions of spans with compression. The template sets CLICKHOUSE_CLUSTER_ENABLED=false accordingly; if you ever outgrow it, the catalogue’s 3-node clickhouse template is the upgrade path. ## LiteLLM URL: https://deployable.sh/apps/litellm/ Category: LLM Infrastructure Upstream: LiteLLM, https://docs.litellm.ai Template source: https://github.com/deployable-sh/stacks/tree/main/litellm Every team using LLMs converges on the same needs: one endpoint instead of five SDKs, per-team API keys instead of the shared provider key in a Slack DM, budgets before the invoice surprise, and a log of who spent what on which model. LiteLLM is the open-source gateway that does exactly this - an OpenAI-compatible proxy in front of 100+ providers. This template runs the database-backed mode on a managed Postgres: virtual keys, teams, budgets, and spend logs all persist, and models are managed in the admin UI (/ui) with no config file - STORE_MODEL_IN_DB keeps provider credentials encrypted in the database. The hosted alternatives take a cut or meter your logs; OpenRouter adds 5.5% on credits, Portkey meters logged requests. A self-hosted gateway charges neither - your provider keys, your spend caps, LAN latency from the agents in your project. Footprint: 3 GiB RAM, 5 GB disk, 2 service(s). Miget sizing: Hobby 4 GiB plan at $25/mo; Professional 4 GiB at $43/mo. Managed-service comparison (June 2026): OpenRouter pay-as-you-go (usage-based); Portkey Production ~$49/mo. FAQ: Q: How does this compare to OpenRouter? A: OpenRouter is excellent for instant multi-model access but adds a 5.5% fee on credits and routes your traffic through their infrastructure. Self-hosted LiteLLM uses your own provider keys at raw provider prices, keeps prompts inside your network, and adds the team controls (budgets, virtual keys) OpenRouter does not. Q: Do my existing OpenAI-SDK apps work with it? A: Yes - that is the design. Point base_url at your gateway (http://litellm:5000/v1 in-project, or the public domain) with a virtual key, and the same SDK call can hit Claude, GPT, or Gemini depending on the model name and your routing config. Q: Where do provider API keys live? A: Encrypted in Postgres using LITELLM_SALT_KEY, managed through the admin UI. Generate the salt key before adding the first model and never rotate it - it cannot be changed once credentials are stored. Q: Is it safe to expose the proxy publicly? A: Every request requires a key (master or virtual), so the public domain is usable by external clients. For purely internal use, in-project apps can call http://litellm:5000 and you can keep usage gated by virtual keys per team or agent. Q: Does it pair with the other LLM templates here? A: Naturally: point agent-box, OpenClaw, or Hermes at the gateway for spend caps per agent, and send LiteLLM callbacks to the langfuse template for tracing - the whole LLM platform, self-hosted in one project. ## SQL Server URL: https://deployable.sh/apps/mssql/ Category: Databases Upstream: Microsoft SQL Server 2025, https://learn.microsoft.com/en-us/sql/linux/quickstart-install-connect-docker Template source: https://github.com/deployable-sh/stacks/tree/main/mssql Plenty of stacks are married to SQL Server - .NET shops, legacy line-of-business apps, vendors who only certify against MSSQL. What is less known: Microsoft licenses the Express edition for production at no cost, and SQL Server 2025 raised its ceiling to 50 GB per database. That covers a remarkable number of real workloads. This template runs the official Linux container (mcr.microsoft.com/mssql/server:2025) internal-only - databases never get a public domain - with data on a persistent volume. Two variables: an explicit ACCEPT_EULA=Y (your acceptance, not baked in) and the sa password. Need Standard or Enterprise? Set MSSQL_PID to your licensed edition - the container model is bring-your-own-license, and setting the PID is the attestation. Developer editions stay out of production; this template defaults to the edition that is actually free there. Footprint: 2 GiB RAM, 10 GB disk, 1 service(s). Miget sizing: Hobby 2 GiB plan at $13/mo; Professional 2 GiB at $22/mo. Managed-service comparison (June 2026): Azure SQL Database Standard S0 ~$15/mo; AWS RDS for SQL Server Express, db.t3.small ~$34/mo. FAQ: Q: Is it really legal to run SQL Server Express in production for free? A: Yes - Microsoft offers a free production license for Express, linked from their own container deployment docs. The limits are technical, not legal: 50 GB per database (2025), ~1.4 GB buffer pool, up to 4 cores, no SQL Agent. The template defaults to Express for exactly this reason. Q: How does this compare to Azure SQL Database pricing? A: Azure SQL meters compute (DTUs or vCores) plus storage per database, around the clock for always-on workloads. This stack is $13/month flat on a 2 GiB plan - and the same plan still hosts the app that talks to it. For Express-sized workloads the difference is roughly an order of magnitude. Q: Can I bring my own Standard or Enterprise license? A: Yes - set MSSQL_PID=Standard (or Enterprise) and you attest to holding that license; the container does not validate keys. Raise the RAM in compose.miget.yaml accordingly - Standard 2025 can use up to 256 GB of buffer pool if you give it a plan that big. Q: How do my apps connect? A: From the same Miget project: Server=mssql,1433 with the sa credentials (or better, an app login you create on first boot via MSSQL_DB/MSSQL_USER/MSSQL_PASSWORD). The instance is private with no ingress route - exactly how a database should live. Q: Why is there no arm64 image? A: Microsoft only builds SQL Server containers for x86-64, and the old arm64 workaround (Azure SQL Edge) was retired in September 2025. If your platform nodes are amd64 - as Miget standard plans are - this is a non-issue. ## Oracle Database Free URL: https://deployable.sh/apps/oracle/ Category: Databases Upstream: Oracle Database Free (26ai), https://www.oracle.com/database/free/ Template source: https://github.com/deployable-sh/stacks/tree/main/oracle Sometimes the requirement is simply "Oracle": a vendor app certified against it, a team fluent in PL/SQL, an integration test suite that needs the real thing. Oracle Database Free is Oracle’s answer - the genuine database engine (the 26ai line), licensed under the Free Use Terms and Conditions, which explicitly allow internal production use, not just dev and test. The catch is enforced by the software, not a sales call: 2 CPU cores, 2 GB of memory, 12 GB of user data, one instance per host. Within that envelope it is a full Oracle: PL/SQL, partitioning, JSON-relational duality, the works. This template runs the gvenzl/oracle-free image (maintained by Oracle’s own database product manager, redistribution blessed by the FUTC): multi-arch, faster startup than the official build, and an app schema user bootstrapped in FREEPDB1 on first start. Internal-only, 20 GB volume, two passwords. Footprint: 3 GiB RAM, 20 GB disk, 1 service(s). Miget sizing: Hobby 4 GiB plan at $25/mo; Professional 4 GiB at $43/mo. Managed-service comparison (June 2026): AWS RDS for Oracle SE2 (license incl.), db.t3.small ~$57/mo; OCI Base Database Standard, ECPU ~$172/mo; Oracle Autonomous DB Serverless (always-on) ~$493/mo. FAQ: Q: Is Oracle Database Free actually legal for production? A: Yes - the Free Use Terms and Conditions permit "running the Programs for your own internal business operations" alongside dev, test, and demo use. No support contract, no fees, and the resource limits are enforced by the software itself rather than by audits. Q: What happens when I hit the 12 GB data limit? A: The database raises ORA-12954 and stops accepting new data - it does not bill you, it just stops. If your data outgrows Free, that is the moment to discuss a real Oracle license (and a bigger plan), or to ask whether Postgres could take the workload. Q: Why the gvenzl image instead of Oracle’s official one? A: It is maintained by Oracle’s database product management, the FUTC explicitly permits redistribution, and it is better operationally: amd64 + arm64, slimmer variants, faststart builds, and APP_USER bootstrap. The template works with the official container-registry.oracle.com/database/free image too - swap the image and use ORACLE_PWD. Q: How do applications connect? A: From the same Miget project: oracle:1521/FREEPDB1 - e.g. jdbc:oracle:thin:@//oracle:1521/FREEPDB1 with the app user, or sqlplus app/@//oracle:1521/FREEPDB1. The instance is private with no ingress route. Q: How does this compare to Oracle’s cloud database pricing? A: OCI’s always-on managed Oracle offerings meter ECPUs and storage by the hour and land at multiples of this $25/month plan. Oracle even has an Always Free tier on OCI - the honest comparison - but it ties you to OCI; this template puts the same free engine next to your apps on your platform. ## Ghost URL: https://deployable.sh/apps/ghost/ Category: CMS & Publishing Upstream: Ghost 6, https://ghost.org Template source: https://github.com/deployable-sh/stacks/tree/main/ghost Ghost is what serious independent publishing runs on: a fast editor, built-in newsletters, paid memberships with Stripe, and themes that look professional out of the box. The open-source core is the same software Ghost(Pro) hosts - which means the only question is who runs it. This template answers that with one app container plus a self-hosted MySQL 8 container (Ghost requires MySQL 8 in production; SQLite is dev-only upstream). Themes and images persist on a content volume; posts and members live in the database. The economics favor self-hosting more as you grow: Ghost(Pro) tiers by members and staff, Substack takes 10% of paid subscriptions forever. Self-hosted Ghost has no member cap and keeps every cent of revenue - the $13/month plan is the whole infrastructure bill. Footprint: 2 GiB RAM, 10 GB disk, 2 service(s). Miget sizing: Hobby 2 GiB plan at $13/mo; Professional 2 GiB at $22/mo. Managed-service comparison (June 2026): Ghost(Pro) Starter ~$18/mo; Substack free + cut (usage-based). FAQ: Q: How does self-hosted Ghost compare to Ghost(Pro) and Substack? A: Ghost(Pro) Starter is $18/month for 1,000 members and one staff user; Substack is free but takes 10% of paid-subscription revenue forever. Self-hosted Ghost on this $13/month stack has no member or staff caps and a 0% platform fee - past your first handful of paid subscribers, it wins on pure math. Q: Is it the same Ghost as the hosted product? A: Yes - Ghost(Pro) runs the same open-source core. Self-hosting even removes a tier gate: custom themes work without the $29/month Publisher plan. Q: What about sending the newsletters? A: Transactional email (signups, logins) needs SMTP - any provider works via the mail__* env vars. Bulk newsletter delivery uses Mailgun, configured in the admin UI; that is an upstream Ghost design decision, identical for any self-hosted Ghost. Q: Why does the template require MySQL? A: Ghost supports only MySQL 8 in production (SQLite is dev-only upstream). This template ships a MySQL 8 container wired to Ghost out of the box, so that requirement is covered with no extra setup. ## WordPress URL: https://deployable.sh/apps/wordpress/ Category: CMS & Publishing Upstream: WordPress, https://wordpress.org Template source: https://github.com/deployable-sh/stacks/tree/main/wordpress WordPress needs no introduction - it needs decent hosting. The hosted offerings gate the interesting parts: WordPress.com only allows plugins from its $25/month Business tier, WP Engine meters visits. Self-hosted WordPress is just WordPress: every plugin, every theme, your files. This template runs the official image behind a thin nginx proxy (the Apache variant listens on :80, the platform publishes :5000) with the X-Forwarded-Proto handling already wired, so https behind the platform’s TLS ingress works without the classic redirect loop. The MySQL container is deployed and connected automatically. The entire install - core, plugins, themes, uploads - lives on a persistent volume, so updates from the admin UI behave exactly as on any classic host. Run the 5-minute installer and you have the web’s default CMS on infrastructure you control. Footprint: 2 GiB RAM, 15 GB disk, 3 service(s). Miget sizing: Hobby 2 GiB plan at $13/mo; Professional 4 GiB at $43/mo. Managed-service comparison (June 2026): WordPress.com Business ~$25/mo; WP Engine Startup ~$30/mo. FAQ: Q: How does this compare to WordPress.com or WP Engine? A: WordPress.com only allows plugin installs from the Business tier ($25/month annual, $40 monthly); WP Engine starts at $30/month with a 25k visit cap. This stack is $25/month with no caps and root-level freedom - with the MySQL database bundled into the stack, nothing extra to wire up. Q: Do plugin and core updates work from the admin UI? A: Yes - the whole install lives on the persistent volume, so one-click updates, plugin installs, and media uploads behave exactly like classic hosting and survive redeploys. Q: Can I run WooCommerce on it? A: Yes - it is a plugin like any other. Give the stack the next plan up (WooCommerce is heavier on PHP workers and MySQL) and configure a persistent object cache if traffic grows. Q: Why is there an nginx proxy in front? A: The official Apache image listens on port 80 with no env to change it, and the platform publishes port 5000. The 128 MiB proxy bridges that and forwards the proto headers WordPress needs behind TLS. ## Metabase URL: https://deployable.sh/apps/metabase/ Category: Monitoring & Analytics Upstream: Metabase OSS, https://www.metabase.com Template source: https://github.com/deployable-sh/stacks/tree/main/metabase Metabase’s superpower is that the marketing team uses it without filing tickets: point-and-click questions, sensible charts, dashboards, and scheduled email reports - with full SQL one click away for those who want it. It connects to practically every database. This template runs the OSS image with its app database on a managed Postgres (the embedded H2 default is explicitly non-production upstream - this template never touches it). With the external app DB the container is stateless: questions, dashboards, and users live in Postgres; your analytics data stays in the warehouses Metabase queries. It pairs naturally with the rest of the catalogue: point it at your clickhouse, timescaledb, mssql, or mongodb stacks by service name and the whole project gets dashboards. Footprint: 3 GiB RAM, 5 GB disk, 2 service(s). Miget sizing: Hobby 4 GiB plan at $25/mo; Professional 4 GiB at $43/mo. Managed-service comparison (June 2026): Metabase Cloud Starter ~$100/mo. FAQ: Q: How does self-hosted Metabase compare to Metabase Cloud? A: Metabase Cloud Starter is $100/month base for 5 users plus $6 per extra user. This stack is $25/month flat with unlimited users on the identical OSS core. Cloud buys you their hosting and upgrades; the Pro feature set (SSO, sandboxing) is a separate $575/month tier in either case. Q: Where does my data live? A: Your analytics data never moves - Metabase queries your databases where they are. Only the app database (questions, dashboards, users) lives in the managed Postgres, which is exactly what gets backed up. Q: Can it query the other stacks in this catalogue? A: Yes - in-project databases are reachable by service name: clickhouse ch-1:8123, timescaledb:5432, mssql:1433, mongo-1:27017. Add them as data sources and dashboard the lot without anything leaving the project network. Q: Why does the template insist on an external app database? A: Metabase’s embedded H2 is documented as non-production - it corrupts under concurrent use and complicates upgrades. The managed Postgres removes the failure mode entirely and makes the Metabase container disposable. ## Directus URL: https://deployable.sh/apps/directus/ Category: CMS & Publishing Upstream: Directus 11, https://directus.io Template source: https://github.com/deployable-sh/stacks/tree/main/directus Directus takes a refreshingly honest approach to headless CMS: it introspects a plain Postgres database and instantly serves REST and GraphQL APIs plus a polished admin studio over it. Your schema stays normal SQL - no proprietary content model lock-in, and anything else (BI tools, scripts, this catalogue’s Metabase) can query the same tables. This template runs Directus 11 on a managed Postgres with an uploads volume. Three variables bootstrap it: a SECRET, and the first admin’s email and password. Set PUBLIC_URL after first deploy and the studio, auth flows, and asset URLs all line up. The license story is unusual: self-hosting Directus is free at any scale (BSL source-available); what costs money is their cloud hosting, from $99/month. This stack does that part for $13. Footprint: 2 GiB RAM, 10 GB disk, 2 service(s). Miget sizing: Hobby 2 GiB plan at $13/mo; Professional 2 GiB at $22/mo. Managed-service comparison (June 2026): Directus Cloud hosting add-on ~$99/mo. FAQ: Q: Directus or Strapi? A: Directus if you want the database to stay a normal Postgres schema you own (it introspects; nothing is locked into the CMS), Strapi if you prefer code-first content-type definitions in a Node project. Operationally Directus is the lighter, single-container deploy - which is why it is the one in this catalogue first. Q: What does the BSL license mean for me? A: Self-hosting for your own projects and clients is free at any scale. The Business Source License mainly restricts offering Directus itself as a competing hosted service. For the standard agency/product use case, nothing changes versus open source. Q: How does $13/month compare to Directus Cloud? A: Directus Cloud’s cheapest hosting add-on is $99/month for 3 seats and 25 collections. Self-hosted has no seat or collection limits - the software is identical, you are only replacing their hosting line item. Q: Can other tools query the same database? A: Yes - that is the design. The schema is plain Postgres, so Metabase dashboards, ETL jobs, or any in-project app can read the same tables Directus manages, by service name, without going through the API. ## NocoDB URL: https://deployable.sh/apps/nocodb/ Category: Internal Tools Upstream: NocoDB, https://nocodb.com Template source: https://github.com/deployable-sh/stacks/tree/main/nocodb Airtable’s genius was making databases feel like spreadsheets; its pricing makes growth feel like a penalty - per seat, per month, with hard record caps per base. NocoDB delivers the same grid/kanban/gallery/form experience as open source over a real database. This template runs NocoDB on a managed Postgres with a small volume for file attachments. One secret (the JWT signing key) and it boots; the first account becomes admin. Two superpowers over the SaaS original: no meters of any kind, and the data lives in actual Postgres - NocoDB can even mount your existing in-project databases as external sources, putting a spreadsheet UI over data you already have. Footprint: 3 GiB RAM, 10 GB disk, 2 service(s). Miget sizing: Hobby 4 GiB plan at $25/mo; Professional 4 GiB at $43/mo. Managed-service comparison (June 2026): Airtable Team ~$200/mo. FAQ: Q: How does NocoDB pricing compare to Airtable? A: Airtable Team is $20/seat/month - $200/month for a 10-person team - with 50k records per base. This stack is $25/month flat, unlimited seats and records. The crossover is at two users. Q: Can NocoDB sit on top of a database I already have? A: Yes - beyond its own Postgres, NocoDB connects external Postgres/MySQL databases as data sources. Point it at other stacks in your project by service name and non-developers get a safe spreadsheet UI over production data. Q: Is my data locked into NocoDB? A: No - it is rows in Postgres. Export via API or query the database directly; if you ever leave, the data is already in the most portable format there is. Q: What is the license situation? A: NocoDB Community uses a fair-code Sustainable Use License: free to self-host for internal use at any scale; restrictions target reselling NocoDB itself as a service. Same family of license as n8n, same practical answer. ## Forgejo URL: https://deployable.sh/apps/forgejo/ Category: Dev Tools Upstream: Forgejo (Codeberg e.V.), https://forgejo.org Template source: https://github.com/deployable-sh/stacks/tree/main/forgejo A team forge is the classic self-host win: code is the asset you least want metered or mined, and a Go binary serves it from a gigabyte of RAM. Forgejo is the community-governed hard fork of Gitea - run by the non-profit Codeberg e.V., GPL-licensed, monthly security releases - with everything a small forge needs: repos, issues, PRs, packages, and GitHub-Actions-compatible CI via Forgejo Actions. This template runs Forgejo on a managed Postgres with repos on a 10 GB volume. It deliberately ships HTTPS-first: git clone over https with tokens covers the full workflow on an HTTP-first platform, and SSH can be enabled over a custom TCP port if you want it. Why Forgejo over Gitea? Governance: Gitea’s trademark moved to a for-profit in 2022; Forgejo answered with a non-profit home and an independent release train. Same lineage, community steering wheel - the safer two-decade bet for where your code lives. Footprint: 2 GiB RAM, 15 GB disk, 2 service(s). Miget sizing: Hobby 2 GiB plan at $13/mo; Professional 4 GiB at $43/mo. Managed-service comparison (June 2026): GitHub Team ~$40/mo; GitLab Premium ~$290/mo. FAQ: Q: Forgejo or Gitea - which should I deploy? A: They remain very similar technically; the difference is governance. Forgejo lives under the non-profit Codeberg e.V. with GPL licensing and an independent release cadence, after Gitea’s trademark moved to a for-profit. For infrastructure you intend to keep for years, the community-governed fork is the conservative choice - and the env config maps 1:1 if you ever switch. Q: How does this compare to GitHub Team or GitLab Premium? A: GitHub Team is $4/user/month with metered CI minutes; GitLab Premium is $29/user/month. A 10-person team pays $40-290/month there - this stack is $13/month flat with unlimited repos, users, and Actions minutes bounded only by your runners. Q: Can I run CI on it? A: Yes - Forgejo Actions speaks the GitHub Actions workflow format, so most existing workflows port over. Deploy runner(s) as separate apps in the project and register them against your forge; size them to your build load, not the forge. Q: How do I clone without SSH? A: git clone https://your-domain/org/repo with a personal access token works everywhere and is the default here. Want SSH anyway? Add a custom TCP port on the app, enable SSH in the env, and set SSH_PORT to the public port so clone URLs come out right. ## Open Mercato URL: https://deployable.sh/apps/open-mercato/ Category: Internal Tools (experimental) Upstream: Open Mercato, https://github.com/open-mercato/open-mercato Template source: https://github.com/deployable-sh/stacks/tree/main/open-mercato Open Mercato is built on an observation about AI-assisted teams: code assistants generate code fine, but someone still has to decide where it goes. The framework ships those decisions - module layout, multi-tenancy, RBAC, event flow, CRM/ERP/commerce domain models - as conventions and specs checked into the repo, so agents (and juniors) extend it without reinventing architecture. Practically, you get business-app building blocks at "80% done": CRM entities, sales pipeline, order management, dynamic forms, organization trees, feature-flag RBAC - on a modern stack (Next.js, TypeScript, MikroORM) with Postgres+pgvector, a Valkey cache, and Meilisearch behind it. This template mirrors the official full-app topology. Upstream publishes no images yet, so the app builds from the official repo on deploy - which is also why this one wears the experimental badge: pre-1.0, moving fast, and very much worth watching. Footprint: 5.5 GiB RAM, 20 GB disk, 4 service(s). Miget sizing: Hobby 8 GiB plan at $49/mo; Professional 8 GiB at $85/mo. FAQ: Q: Is Open Mercato a shop, a CRM, or a framework? A: A foundation framework with domain modules: you assemble CRM, ERP, B2B-portal, or commerce-backend apps from ready pieces and extend them - ideally with AI agents, which the repo structure is explicitly designed for. If you want a turnkey storefront, PrestaShop in this catalogue is that; Open Mercato is what agencies build bespoke systems on. Q: Why does it build from source? A: Upstream publishes no container images yet (pre-1.0). The template uses a git build context against the official repo with their own Dockerfile, so deploys track upstream. Pin a tag or commit in compose.yaml once you go to production. Q: Why not the managed Postgres? A: Open Mercato uses pgvector for its hybrid indexing and AI features, and managed Postgres offerings do not ship the extension - so the template runs the pgvector image as a private container with its own volume. Q: Who is behind it? A: Catch The Tornado - the team of Piotr and Tomasz Karwatka, previously of Divante and Vue Storefront. MIT-licensed, launched 2025, moving quickly; treat version pins seriously and read upstream release notes before redeploying. ## PrestaShop URL: https://deployable.sh/apps/prestashop/ Category: CMS & Publishing Upstream: PrestaShop 9, https://www.prestashop-project.org Template source: https://github.com/deployable-sh/stacks/tree/main/prestashop PrestaShop runs an enormous share of European e-commerce for a simple reason: it is a complete shop - catalogue, cart, checkout, taxes, multi-language, multi-currency, a serious back office - that charges nothing per month and takes nothing per sale. Your gateway rates are the only per-transaction cost. This template runs the official PrestaShop 9 image with true auto-install: the installer runs on first boot against the MySQL container and removes itself. An nginx proxy fronts Apache (the image listens on :80), and the whole shop persists on a volume so module installs behave like classic hosting. One sharp edge, flagged honestly: PS_DOMAIN is baked into the database at install time - set the final domain before first deploy. The README walks through it; get that one right and the rest is shopping. Footprint: 2 GiB RAM, 15 GB disk, 3 service(s). Miget sizing: Hobby 2 GiB plan at $13/mo; Professional 4 GiB at $43/mo. Managed-service comparison (June 2026): Shopify Basic ~$29/mo; BigCommerce Core ~$29/mo. FAQ: Q: How does this compare to Shopify economically? A: Shopify Basic is $29/month plus 2.9% + 30¢ per card transaction - and 2% extra if you use a non-Shopify gateway. PrestaShop here is $25/month flat with 0% platform fees; at €5,000 of monthly sales the percentage alone exceeds the entire infrastructure bill. Q: What is the PS_DOMAIN warning about? A: PrestaShop writes the shop domain into the database during installation. Set PS_DOMAIN to the real domain (custom or the app’s platform host) before the first deploy; changing it later happens in the back office, not in env. It is the one setup step that cannot be hand-waved. Q: How do upgrades work? A: Like classic PrestaShop hosting: the shop lives on its volume, so bumping the image tag does not upgrade an installed shop - use the official 1-click upgrade module from the back office, with a backup first. Q: Is PrestaShop still a good choice vs headless platforms? A: For a store that needs to exist this month with a theme, checkout, and EU tax handling - yes, emphatically. Headless (Saleor, Medusa) wins when you are building a custom frontend with developer time to spend. Different jobs; this one ships fastest. ## code-server URL: https://deployable.sh/apps/code-server/ Category: Dev Tools Upstream: code-server (Coder), https://github.com/coder/code-server Template source: https://github.com/deployable-sh/stacks/tree/main/code-server code-server is the original "VS Code in a browser tab": the full editor - extensions, terminal, debugger - served from a container you own. Open it from a desktop, a tablet, or a borrowed machine, and your environment is exactly where you left it. This template is one container with a 10 GB home volume: settings, extensions, and cloned repos all persist across redeploys. Password auth in front, your toolchains inside - apt and language runtimes install like on any dev box. It completes the catalogue’s remote-dev story: agent-box gives you Claude Code and opencode in a terminal; code-server gives you the IDE. Same flat-price logic against Codespaces-style hourly metering - a box that is always on costs $13/month, not cents-per-minute anxiety. Footprint: 2 GiB RAM, 10 GB disk, 1 service(s). Miget sizing: Hobby 2 GiB plan at $13/mo; Professional 2 GiB at $22/mo. FAQ: Q: How does this compare to GitHub Codespaces? A: Codespaces bills by the core-hour plus storage, which is great for spiky use and stressful for always-on. This box is $13/month flat, always warm, with state that never gets reclaimed. The trade: you maintain the toolchain inside it - which for a personal dev box is usually a feature. Q: Can I use my VS Code extensions? A: code-server installs from Open VSX, which carries the large majority of popular extensions. A few Microsoft-proprietary ones (the official C# debugger, Live Share) are licensed only for official builds - the honest caveat of every VS Code fork. Q: Is it safe to expose an IDE to the internet? A: It sits behind password auth over the platform’s TLS, like the catalogue’s other dev boxes. Use a long random password, keep real secrets in env rather than files where possible, and treat it like any machine that can run code - because it is one. Q: code-server or agent-box? A: code-server when you want to write code in an IDE from anywhere; agent-box when you want agents (Claude Code, opencode) doing the writing in a persistent tmux session. Many people run both against the same repos - they are $5-13/month each, not a platform decision. ## Saleor URL: https://deployable.sh/apps/saleor/ Category: CMS & Publishing Upstream: Saleor, https://saleor.io Template source: https://github.com/deployable-sh/stacks/tree/main/saleor Saleor is what e-commerce looks like when the API comes first: a single GraphQL endpoint covering products, channels, checkout, payments, and orders, built for teams shipping custom storefronts. BSD-3 licensed, with official images - the rare headless commerce platform that is genuinely deployable rather than scaffold-only. This template mirrors the official saleor-platform topology: API core and Celery worker on a managed Postgres, a noeviction Valkey broker, the dashboard SPA, and a migrate sidecar that applies migrations and bootstraps your superuser. The API and dashboard each get their own domain via thin nginx proxies. The pricing contrast is the starkest on this site: Saleor Cloud starts at $1,599/month (Select tier, then 0.8% of GMV overage). The identical BSD core on this stack runs $25-49/month with no GMV arithmetic at all. Footprint: 4.8 GiB RAM, 10 GB disk, 8 service(s). Miget sizing: Hobby 8 GiB plan at $49/mo; Professional 8 GiB at $85/mo. Managed-service comparison (June 2026): Saleor Cloud Select ~$1599/mo; Shopify Grow ~$79/mo. FAQ: Q: Why is Saleor Cloud $1,599/month when this is $25? A: Saleor Cloud is positioned for funded mid-market teams: its Select tier bundles $200K/month GMV, SLAs, and their ops. The BSD-3 core is the same software - self-hosting trades their ops team for your deploy button, and removes GMV percentages from your unit economics entirely. Q: Saleor or PrestaShop - which one for my shop? A: PrestaShop if you want a complete store this week: theme, checkout, EU taxes, done. Saleor if you are building a custom storefront and want a clean GraphQL API behind it. Both are in this catalogue; they solve different problems. Q: Where is the storefront? A: Saleor is deliberately headless - bring your own frontend. Their open-source Next.js storefront starter connects to your API URL out of the box and is the fastest way to see your products rendered. Q: What happens on upgrades? A: Migrations run automatically via the migrate sidecar on every deploy. The one rule: bump the api and dashboard tags together - the dashboard minor version must match the core. ## Grafana Stack URL: https://deployable.sh/apps/grafana-stack/ Category: Monitoring & Analytics Upstream: Grafana + Prometheus + Loki, https://grafana.com/oss/ Template source: https://github.com/deployable-sh/stacks/tree/main/grafana-stack Observability SaaS has the most creative meters in the industry: per host, per million spans, per GB ingested, per active series. The open-source answer has been stable for years - Grafana for dashboards, Prometheus for metrics, Loki for logs - and it deploys beautifully as one small stack. This template wires the three together: Grafana public with both datasources pre-provisioned, Prometheus private with a baked config (the officially documented pattern) you extend with your apps’ /metrics endpoints by service name, and Loki private in its stock single-binary filesystem mode - apps push logs straight to its HTTP API. Deliberately absent: node-exporter and cadvisor, which need host access a PaaS cannot grant - node metrics are the platform’s job. This stack is for your applications’ metrics and logs, which is the part you actually dashboard. Footprint: 1.5 GiB RAM, 22 GB disk, 3 service(s). Miget sizing: Hobby 2 GiB plan at $13/mo; Professional 4 GiB at $43/mo. Managed-service comparison (June 2026): Grafana Cloud Pro (usage) (usage-based); Datadog Infrastructure Pro ~$15/mo. FAQ: Q: How does this compare to Datadog or Grafana Cloud? A: Datadog Infrastructure Pro is $15-18 per host per month before logs and custom metrics. Grafana Cloud has a genuinely generous free tier, but the Pro meters ($6.50 per 1k metric series, ~$0.55/GB for logs all-in) compound with growth. This stack is $13/month flat - the same Grafana, your retention rules. Q: How do my apps get metrics into it? A: Expose /metrics with any Prometheus client library, add the service name to prometheus.yml in the template, redeploy. In-project targets are scraped over the private network - nothing public required. Q: How do logs get into Loki? A: Apps push directly to http://loki:3100/loki/api/v1/push - every major logging library has a Loki sink, and OTLP works too. (Promtail reached end-of-life in March 2026, and on a PaaS there are no host log files to tail anyway - pushing is the right model.) Q: Why no node-exporter or cadvisor? A: Both need host-level access (host network, /proc, the Docker socket) that platform sandboxes cannot grant - and node health is the platform’s responsibility anyway. Application metrics and logs are what this stack is for. ## Open WebUI URL: https://deployable.sh/apps/open-webui/ Category: LLM Infrastructure Upstream: Open WebUI, https://openwebui.com Template source: https://github.com/deployable-sh/stacks/tree/main/open-webui Team AI chat subscriptions charge per seat for what is mostly a UI: ChatGPT Business and Claude Team both land around $25 per user per month before anyone sends a token. Open WebUI is the self-hosted answer - a polished, fast chat workspace over any OpenAI-compatible API, with the team features (accounts, RBAC, shared prompts, document RAG) included. One container, one volume, one secret. Users sign up (first account is admin, the rest need approval), upload documents for retrieval, and chat against whatever models you connect. No GPU involved - models run at your API providers. The strongest deployment pairs it with this catalogue’s litellm gateway: every provider behind one base URL, per-team budgets on virtual keys, and this UI in front. A 10-person team pays raw token prices plus $13/month - versus ~$250/month in seats before usage. Footprint: 2 GiB RAM, 5 GB disk, 1 service(s). Miget sizing: Hobby 2 GiB plan at $13/mo; Professional 2 GiB at $22/mo. Managed-service comparison (June 2026): ChatGPT Business per seat ~$250/mo; Claude Team per seat ~$250/mo. FAQ: Q: How does this compare to ChatGPT Business or Claude Team? A: Both charge ~$25/seat/month ($20 annual) - $250/month for ten people, before usage. Open WebUI + LiteLLM pays raw API token prices with no seat fee: for typical internal usage that is a fraction of the subscription cost, and you choose models per conversation. Q: Does it need Ollama or a GPU? A: No - this template deliberately uses the API-only image. Connect any OpenAI-compatible endpoint (OpenAI, Anthropic via LiteLLM, Gemini, your own vLLM elsewhere). The :ollama variant exists for local models, but that is a different RAM/GPU conversation. Q: How does the RAG feature work? A: Upload documents in the UI; Open WebUI chunks and embeds them into its built-in vector store and injects relevant passages into chats. For heavier knowledge bases, it supports external vector stores - the catalogue’s qdrant template plugs in via VECTOR_DB settings. Q: What is the licensing situation? A: Open WebUI uses a BSD-3-derived license with a branding-protection clause: keep the Open WebUI branding visible (fine for internal deployments; white-labeling it as your own product requires their enterprise license). ## Flowise URL: https://deployable.sh/apps/flowise/ Category: LLM Infrastructure Upstream: Flowise, https://flowiseai.com Template source: https://github.com/deployable-sh/stacks/tree/main/flowise Flowise is the visual layer of the LLM stack: drag models, vector stores, tools, and memory onto a canvas, wire them into chatflows or multi-agent flows, and ship the result as an API or an embeddable chat widget. For teams where not everyone writes LangChain by hand, it is the fastest route from idea to working assistant. This template runs Flowise v3 on a managed Postgres (flows, users, credentials) with a volume for uploaded files. v3 auth means accounts are created in the UI on first visit; four secrets in env keep sessions and stored provider credentials stable across redeploys. It slots into the catalogue’s LLM lane end to end: models via the litellm gateway, vectors in qdrant or chromadb, traces to langfuse - every connection by service name, nothing leaving the project network. Footprint: 2 GiB RAM, 10 GB disk, 2 service(s). Miget sizing: Hobby 2 GiB plan at $13/mo; Professional 2 GiB at $22/mo. Managed-service comparison (June 2026): Flowise Cloud Starter ~$35/mo; Dify Cloud Professional ~$59/mo. FAQ: Q: How does this compare to Flowise Cloud and Dify Cloud? A: Flowise Cloud Starter is $35/month capped at 10,000 predictions; Dify Cloud Professional is $59/month for 5,000 message credits. Self-hosted Flowise is $13/month with no prediction meter - the flows run against your own provider keys. Q: Where did the FLOWISE_USERNAME/PASSWORD login go? A: Flowise v3 replaced the shared-credential envs with real accounts: visit the app once after deploy and create the admin user in the setup screen. The env secrets in this template sign those sessions; they are not a login. Q: Flowise or n8n for automation? A: n8n (also in this catalogue, in queue mode) is general workflow automation with LLM nodes; Flowise is purpose-built for conversational AI - chat memory, RAG patterns, agent tools, and an embeddable widget. Many teams run both for different jobs. Q: How do I embed a bot on my site? A: Each flow exposes an API endpoint and an embed snippet (script tag or React component) pointing at your domain. Keep the flow’s API key server-side for private flows; public chat widgets use the public endpoint with rate limits. ## Jenkins URL: https://deployable.sh/apps/jenkins/ Category: Dev Tools Upstream: Jenkins LTS, https://www.jenkins.io Template source: https://github.com/deployable-sh/stacks/tree/main/jenkins Jenkins is unfashionable and unkillable: pipelines as code, an integration for literally everything, and two decades of answers on every error message you will ever see. For teams that want CI they own - cron-scheduled jobs, deploy pipelines, glue automation - it remains the pragmatic choice. This template runs the LTS controller with its built-in node, which executes jobs in-controller: the honest, right-sized shape for small teams. Everything (config, plugins, jobs, history) persists on the jenkins_home volume. The PaaS reality is documented rather than hidden: there is no Docker socket, so jobs build artifacts with toolchains in the container and build images with rootless tools (kaniko-style) - and when builds outgrow the controller, inbound agents deploy as separate apps in the same project. Footprint: 2 GiB RAM, 10 GB disk, 1 service(s). Miget sizing: Hobby 2 GiB plan at $13/mo; Professional 2 GiB at $22/mo. FAQ: Q: Why Jenkins in 2026 instead of GitHub Actions? A: Minutes and ownership. Hosted CI meters every build minute past the included quota; Jenkins on a $13/month plan runs unlimited jobs. It also does things Actions does not: long-lived stateful jobs, cross-repo orchestration, and pipelines against forges you self-host - like the forgejo template next to it. Q: Can jobs build Docker images here? A: Not with the Docker daemon - the platform exposes no socket. Use rootless image builders (kaniko, buildah) inside jobs, or let Miget itself build images from your repos. Plain build/test/deploy jobs need nothing special. Q: How do I add build capacity? A: Deploy jenkins/inbound-agent as a separate app in the project, create a node in the controller UI, and start the agent with the node secret pointing at http://jenkins:5000. Agents scale and get RAM independently of the controller. Q: Where is the initial admin password? A: In /var/jenkins_home/secrets/initialAdminPassword inside the container - read it from the app shell or logs on first boot, then complete the setup wizard. After that, auth is whatever you configure (local users, OIDC via plugin, even the keycloak template). ## GitHub Actions Runner URL: https://deployable.sh/apps/github-runner/ Category: Dev Tools Upstream: actions/runner (via myoung34 image), https://docs.github.com/en/actions/hosting-your-own-runners Template source: https://github.com/deployable-sh/stacks/tree/main/github-runner GitHub Actions minutes are the quiet line item that grows with every push: $0.006/minute for Linux 2-core past the included quota, more for bigger machines. A self-hosted runner removes the meter - and gets you exactly the CPU, RAM, and caching behavior you choose. This template uses the de-facto env-driven runner image with PAT-based auto-registration: set a token and a repo (or org), deploy, and the runner appears in Settings > Actions. Registration state persists across redeploys; EPHEMERAL mode plus replicas gives clean-slate scale-out. The honest constraint, documented rather than discovered: run: steps and JS/composite actions work fully; container: jobs and Docker container actions need a daemon a PaaS does not expose - image builds go through kaniko or buildah instead. Footprint: 2 GiB RAM, 1 GB disk, 1 service(s). Miget sizing: Hobby 2 GiB plan at $13/mo; Professional 2 GiB at $22/mo. Managed-service comparison (June 2026): GitHub Actions hosted runners (usage-based). FAQ: Q: How much does this save vs hosted runners? A: GitHub includes 2,000-3,000 minutes/month on Free/Team plans, then bills $0.006/min for Linux 2-core. A team burning 30,000 monthly minutes pays ~$165 in overage; this runner is $13/month flat at any volume - and you can give it more cores than the hosted 2-core default for the same price. Q: What workflows will NOT work on it? A: Anything needing the Docker daemon: container: jobs, services: blocks (Postgres-in-CI style), and Docker container actions. The fixes are standard: native services (your project already runs real databases), kaniko/buildah for image builds, and JS-based actions which all work. Q: How do I run more jobs in parallel? A: Set EPHEMERAL=true and raise replicas - each replica registers itself, takes one job, deregisters, repeats. Clean state per job, parallelism equal to replica count, all inside the same flat plan. Q: Is a PAT in env safe? A: The token only mints runner registration tokens and lives server-side in your stack env. Use a fine-grained PAT scoped to the one repo/org, and rotate it like any credential. GitHub’s JIT-config flow exists for stricter setups; this template favors the simple, durable registration. ## GitLab Runner URL: https://deployable.sh/apps/gitlab-runner/ Category: Dev Tools Upstream: GitLab Runner, https://docs.gitlab.com/runner/ Template source: https://github.com/deployable-sh/stacks/tree/main/gitlab-runner GitLab meters CI by compute minutes - 400/month on Free, 10,000 on Premium, $10 per extra thousand. Jobs on your own runner consume zero quota, which converts CI from a metered resource into a fixed cost. This template wraps the official image with a register-on-first-boot entrypoint using the current runner-authentication-token flow (glrt-..., created in the GitLab UI where tags and run-untagged live now; the legacy registration-token flow is deprecated and disabled by default). Registration persists on a volume, so redeploys do not create runner zombies. It runs the shell executor: jobs execute in this container as the gitlab-runner user, with whatever toolchains you bake into the Dockerfile. That is the supported socket-less mode - and the trust model (jobs share the environment) is stated plainly, per GitLab’s own guidance. Footprint: 2 GiB RAM, 5 GB disk, 1 service(s). Miget sizing: Hobby 2 GiB plan at $13/mo; Professional 2 GiB at $22/mo. Managed-service comparison (June 2026): GitLab CI/CD hosted compute (usage-based). FAQ: Q: How does this compare to GitLab’s hosted minutes? A: Free includes 400 compute minutes a month - one active project exhausts that in days - and extra minutes cost $10 per 1,000. Premium’s 10,000 minutes come bundled with $29/user/month seats. This runner is $13/month with no meter at all. Q: Why the shell executor instead of docker? A: The docker executor needs the Docker socket, which a PaaS container does not have. Shell mode runs jobs directly in this container - GitLab supports it (maintenance mode: security fixes continue), and for trusted-team pipelines it is operationally simpler anyway. Q: Where did tags and run-untagged settings go? A: Server-side: with the glrt- token flow you configure them when creating the runner in the GitLab UI, not at register time. The template’s register call intentionally passes only the URL, token, and executor. Q: Can jobs build Docker images? A: Not with the daemon - use kaniko (runs as an unprivileged container step in shell mode too) or buildah. For everything else - tests, builds, deploys via API - nothing changes. ## Forgejo Runner URL: https://deployable.sh/apps/forgejo-runner/ Category: Dev Tools Upstream: Forgejo Actions runner, https://forgejo.org/docs/latest/admin/actions/ Template source: https://github.com/deployable-sh/stacks/tree/main/forgejo-runner Forgejo Actions speaks GitHub Actions workflow syntax, which means the ecosystem muscle memory transfers - but the runners are yours to provide. This template deploys one in host mode: jobs execute as shell steps in the runner container, no Docker daemon required. It pairs perfectly with the catalogue’s forgejo template (point FORGEJO_URL at http://forgejo:5000 and the whole forge + CI story lives in one project) - and it serves Codeberg too, since Codeberg runs Forgejo and lets you register your own runners. Registration uses the v12 declarative flow: create the runner in the UI, copy its UUID and token, deploy. The runner connects outbound; no ingress, no public port, nothing to firewall. Footprint: 2 GiB RAM, 5 GB disk, 1 service(s). Miget sizing: Hobby 2 GiB plan at $13/mo; Professional 2 GiB at $22/mo. FAQ: Q: Does this work with Codeberg? A: Yes - Codeberg runs Forgejo and supports user/org/repo-level self-hosted runners. Create the runner under your Codeberg settings, drop the UUID and token here, and your Codeberg workflows run on your own compute. Q: Will my GitHub Actions workflows just run? A: Mostly - Forgejo Actions implements the workflow syntax and most actions from the ecosystem work. Jobs run with the host label here, so container: jobs and Docker actions need the usual socket-less substitutions (kaniko/buildah for image builds). Q: Forgejo runner or Gitea act_runner? A: Same lineage, matching governance choice: this catalogue ships Forgejo (the forge) so it ships the Forgejo runner. Gitea’s act_runner is configured almost identically (env-based registration) if you run Gitea instead. ## Azure Pipelines Agent URL: https://deployable.sh/apps/azp-agent/ Category: Dev Tools Upstream: Azure Pipelines agent, https://learn.microsoft.com/en-us/azure/devops/pipelines/agents/docker Template source: https://github.com/deployable-sh/stacks/tree/main/azp-agent Azure DevOps prices CI by the parallel job: $40/month per Microsoft-hosted pipeline, $15/month per additional self-hosted one - and the free grant for new organizations currently requires a request form. Bringing your own agent is the documented, encouraged escape hatch. Microsoft ships no agent container image; their docs provide a Dockerfile recipe instead - which is exactly what this template packages. On first boot the agent downloads itself from your organization, registers into the pool with your PAT, and starts taking jobs; on shutdown it deregisters cleanly. Script, checkout, and task steps run in-container. The usual platform note applies: no Docker daemon, so container jobs and Docker tasks stay on hosted agents or switch to rootless builders. Footprint: 2 GiB RAM, 5 GB disk, 1 service(s). Miget sizing: Hobby 2 GiB plan at $13/mo; Professional 2 GiB at $22/mo. Managed-service comparison (June 2026): Azure Pipelines Microsoft-hosted ~$40/mo. FAQ: Q: What does this replace, cost-wise? A: Each Microsoft-hosted parallel job is $40/month; each extra self-hosted parallel job license is $15/month (the first is free). The agent’s compute here rides the same flat plan as the rest of your stack - so a second and third pipeline cost license fees only, not VM bills. Q: Why is there no official agent image? A: Microsoft deliberately documents a build-your-own Dockerfile (the agent version-locks to your org and updates itself). This template is that recipe, faithfully: ubuntu:24.04, the documented start.sh flow, non-root agent user, clean deregistration trap. Q: Do classic and YAML pipelines both work? A: Yes - the agent is the same for both. Target it via the agent pool. Container jobs and Docker@2-style tasks need a daemon this platform does not expose; everything script- and task-based runs normally. ## Buildkite Agent URL: https://deployable.sh/apps/buildkite-agent/ Category: Dev Tools Upstream: Buildkite agent, https://buildkite.com/docs/agent/v3 Template source: https://github.com/deployable-sh/stacks/tree/main/buildkite-agent Buildkite made the architectural choice the other CI vendors are still backing into: the SaaS runs orchestration, UI, and webhooks, while every build executes on agents you control. Compute was never metered because it was never theirs - which makes the agent the cleanest self-hosted runner in this catalogue. Official MIT-licensed image, one required token, tags for queue targeting. Jobs run as shell commands in the container; extend the image with your toolchains and raise replicas for parallelism - agents pull independently from the queue. The standard platform note: no Docker daemon, so plugin-heavy Docker workflows need kaniko/buildah substitutions, while script-based pipelines run untouched. Footprint: 2 GiB RAM, 5 GB disk, 1 service(s). Miget sizing: Hobby 2 GiB plan at $13/mo; Professional 2 GiB at $22/mo. FAQ: Q: Why is Buildkite the “cleanest” runner here? A: Because self-hosted agents are Buildkite’s primary model, not an escape hatch: the official image needs exactly one env var, registration is instant, and there is no minute-metering to escape in the first place. Buildkite charges per user for the control plane; compute was always yours. Q: How do pipelines target this agent? A: Tags: the template sets queue=miget, and pipelines select it with agents: queue: miget. Add more tags (language versions, capabilities) to route specific steps to specific agents. Q: Does Docker-based tooling work? A: The docker-compose and docker plugins need a daemon this platform does not expose. Script steps, artifact upload/download, and the broader plugin ecosystem that shells out work normally - and image builds go through kaniko or buildah like everywhere else in the catalogue. ## Mailpit URL: https://deployable.sh/apps/mailpit/ Category: Email & Newsletters Upstream: Mailpit, https://mailpit.axllent.org Template source: https://github.com/deployable-sh/stacks/tree/main/mailpit Every stack sends email eventually - signups, resets, invoices - and testing it against real inboxes is how staging secrets leak and customers get confused. Mailpit is the modern answer (MailHog stopped updating in 2020): an SMTP sink that catches everything, with a fast UI for search, HTML preview, and link checking. The project-network deployment is the killer version of it: every app in your Miget project points its SMTP settings at mailpit:1025 - Ghost, Chatwoot, Keycloak, Typebot, anything - and all their mail lands in one authenticated UI. No per-inbox setup, no third party seeing your test data. One tiny Go container, one variable, $5/month. Hosted email-testing sandboxes charge ~$14/month for 500 test emails; Mailpit keeps your last 5,000 with no meter. Footprint: 256 MiB RAM, 1 GB disk, 1 service(s). Miget sizing: Hobby 512 MiB plan at $5/mo; Professional 2 GiB at $22/mo. Managed-service comparison (June 2026): Mailtrap Testing Basic ~$14/mo. FAQ: Q: How is this different from Mailtrap? A: Same job - catch test email before it reaches humans - without the meter: Mailtrap’s testing plans start around $14/month for 500 test emails. Mailpit on the $5 plan keeps 5,000 with full search, and your message contents never leave your project. Q: How do apps send to it? A: Set SMTP host mailpit, port 1025, no auth, no TLS - the project network is the boundary, and the SMTP port has no public route. Every template in this catalogue with SMTP settings works against it unchanged. Q: Is this for production email? A: No - deliberately. Mailpit catches mail; it never delivers it. For real sending, configure a relay (SES, Resend, Postmark) in your apps, and use the listmonk template when the job is newsletters. ## listmonk URL: https://deployable.sh/apps/listmonk/ Category: Email & Newsletters Upstream: listmonk, https://listmonk.app Template source: https://github.com/deployable-sh/stacks/tree/main/listmonk Newsletter SaaS prices by subscriber count, which means your bill grows precisely when your project succeeds. listmonk decouples that: a single Go binary on Postgres that manages subscribers, double opt-in, campaigns, templates, and analytics - while delivery goes through whatever relay you configure. That architecture is the honest one for a PaaS: platforms cannot send port-25 mail credibly (nobody can, from shared IPs), so listmonk hands delivery to SES (~$0.10 per 1,000 emails), Resend, Postmark, or Mailgun - configured in the admin UI - and owns everything else. This template is fully env-driven on a managed Postgres, with listmonk’s idempotent install/upgrade running on every deploy. A 50,000-subscriber list that costs hundreds monthly on hosted platforms runs here for $13 plus relay postage. Footprint: 1.5 GiB RAM, 5 GB disk, 2 service(s). Miget sizing: Hobby 2 GiB plan at $13/mo; Professional 2 GiB at $22/mo. Managed-service comparison (June 2026): Resend Pro ~$20/mo; Postmark Basic ~$15/mo. FAQ: Q: What does sending actually cost? A: The relay’s rates: Amazon SES is ~$0.10 per 1,000 emails, Resend Pro is $20/month for 50k, Postmark $15/month for 10k. listmonk adds no per-subscriber or per-send fee on top - a 100k-send month through SES costs about $10 in postage plus this $13 plan. Q: Why not just use the relay’s own campaign tools? A: Ownership and limits: your subscriber list, consent records, and engagement data live in your Postgres, exportable as SQL - and switching relays is a settings change, not a migration. Relay-native tools also tier their campaign features by contact count; listmonk does not count. Q: Does it handle double opt-in and GDPR basics? A: Yes - double opt-in flows, per-list consent, unsubscribe links, and full data export/wipe per subscriber are built in. The public subscription pages run on the same domain. ## authentik URL: https://deployable.sh/apps/authentik/ Category: Auth & API Gateway Upstream: authentik, https://goauthentik.io Template source: https://github.com/deployable-sh/stacks/tree/main/authentik authentik is what teams pick when Keycloak feels like a JVM-shaped commitment: the same core job (OIDC, SAML, LDAP, SCIM, MFA, SSO across your apps) with a visual flow designer - login journeys, conditional access, and enrollment built by composing stages in a UI instead of writing SPIs. The 2025.10 release made it dramatically easier to operate: Redis is gone entirely, with tasks, cache, and sessions all on Postgres. That makes this template a clean pair - server and worker from one image - on the managed Postgres, auto-wired with sslmode=require. Bootstrap is headless (admin password and email in env, applied on first start) and the per-MAU math is the usual story: Auth0 wants $70/month at one thousand users; authentik does not count. Footprint: 2.8 GiB RAM, 6 GB disk, 3 service(s). Miget sizing: Hobby 4 GiB plan at $25/mo; Professional 4 GiB at $43/mo. Managed-service comparison (June 2026): Auth0 Essentials (B2C) ~$70/mo; Okta Starter Suite ~$60/mo. FAQ: Q: authentik or Keycloak - this catalogue has both? A: Deliberately. Keycloak is the two-decade enterprise standard (deep SAML/federation edge cases, Red Hat lineage); authentik is the modern operator’s choice - visual flows, lighter footprint, faster iteration. Same flat-price economics either way; pick by taste and protocol needs. Q: How does it compare to Auth0 pricing? A: Auth0’s free tier is generous now (25k MAU), but the paid cliff is steep: Essentials is $70/month at 1,000 MAU and Professional $240+. authentik on this $25/month stack has no MAU concept at all - users are rows in your Postgres. Q: Really no Redis? A: Really - upstream removed it across 2025.8-2025.10 (tasks, then cache and sessions, all to Postgres). The trade is more Postgres connections, which the managed instance absorbs. Older tutorials showing Redis services are simply outdated. Q: Can it protect apps that have no auth of their own? A: Yes - proxy/forward-auth outposts can sit in front of plain apps. On this platform the embedded outpost in the server covers the common cases; register the app, route through authentik, done. ## Zitadel URL: https://deployable.sh/apps/zitadel/ Category: Auth & API Gateway Upstream: Zitadel, https://zitadel.com Template source: https://github.com/deployable-sh/stacks/tree/main/zitadel Zitadel is the newest generation of identity server: passkeys as a first-class login method, multi-tenant organizations baked into the data model (each B2B customer gets an org with its own users, policies, and branding), and custom logic via JS actions - all in a single stateless Go binary that idles around half a gigabyte. The deployment is the cleanest in the identity lane: one container plus the managed Postgres, fully env-configured, with the masterkey as the only generated secret. The one sharp edge is flagged loudly: the external domain is baked into instance data at first setup - set the final domain before the first deploy. For B2B SaaS builders the comparison is Okta and WorkOS: $6/user/month with a $1,500 annual minimum on one side, $125/month per SSO connection on the other. Zitadel ships SSO connections and orgs as ordinary features of a $13/month stack. Footprint: 2 GiB RAM, 5 GB disk, 2 service(s). Miget sizing: Hobby 2 GiB plan at $13/mo; Professional 2 GiB at $22/mo. Managed-service comparison (June 2026): Okta Starter Suite ~$60/mo; WorkOS SSO connections ~$125/mo. FAQ: Q: Zitadel, authentik, or Keycloak? A: Zitadel for passkeys-first UX, B2B multi-tenancy, and the smallest footprint; authentik for visual flow design and ops comfort; Keycloak for maximum protocol depth and enterprise lineage. All three are in this catalogue at $13-25/month - deploying two to compare costs less than a week of any identity SaaS. Q: What is the external-domain warning about? A: Zitadel writes the domain into its instance data during initial setup - issuer URLs, org domains, and keys derive from it. Set ZITADEL_EXTERNALDOMAIN to your real domain (with EXTERNALPORT=443 and EXTERNALSECURE=true) before the first deploy; changing it afterward is a documented but painful procedure. Q: Does AGPL affect my apps that use it for login? A: No - your applications only talk to Zitadel over OIDC/SAML, which creates no licensing relationship. AGPL obligations would only arise if you modified Zitadel itself and offered that modified version as a service. Q: How does it compare to Okta or WorkOS for B2B? A: Okta Workforce starts at $6/user/month with a $1,500/year minimum; WorkOS charges $125/month per SSO connection. Zitadel makes each customer an organization with their own SSO config - unlimited orgs and connections, on the flat plan. ## DocuSeal URL: https://deployable.sh/apps/docuseal/ Category: Business Apps Upstream: DocuSeal, https://www.docuseal.com Template source: https://github.com/deployable-sh/stacks/tree/main/docuseal E-signature SaaS invented the strangest meter in software: the envelope. DocuSign Standard charges $30 per user per month and still caps you at 100 envelopes a year - sending an NDA twice a week exhausts it. DocuSeal is the open-source answer, and its signing core is genuinely complete in the free edition. You get a WYSIWYG field builder (12 field types), multi-submitter flows, automatic PDF eSignatures with verification, an API, and webhooks - one Rails container on a managed Postgres, with attachments on a volume or S3. Emails drive signature requests, so any SMTP relay plugs in - including the catalogue’s mailpit for testing the flow end-to-end before pointing at a real relay. Footprint: 2 GiB RAM, 10 GB disk, 3 service(s). Miget sizing: Hobby 2 GiB plan at $13/mo; Professional 2 GiB at $22/mo. Managed-service comparison (June 2026): DocuSign Standard ~$30/mo; Dropbox Sign Essentials ~$15/mo; DocuSeal Pro cloud/on-prem ~$20/mo. FAQ: Q: What does the math look like vs DocuSign? A: DocuSign Standard: $30/user/month, 100 envelopes per user per year, overage billed per envelope. DocuSeal here: $25/month total, unlimited users and documents. A 5-person team sending contracts weekly saves over $1,500 a year and stops counting envelopes entirely. Q: Are self-hosted signatures legally valid? A: DocuSeal produces standard PDF eSignatures with verification and a full audit trail - the same technical mechanism the SaaS products use, generally valid for ESIGN/eIDAS-grade consent flows. For qualified/advanced signature regimes, consult counsel; that is true of every e-sign product. Q: What is in the Pro tier I am not getting? A: White-labeling, SSO/SAML, automated reminders, bulk CSV sends, conditional fields, and the embeddable signing components - $20/user/month upstream. The core loop (build template, send, sign, verify, webhook) is fully in the free edition. Q: DocuSeal or Documenso? A: DocuSeal is lighter (half the RAM) and fastest to value; Documenso has the more polished product UX, team management, and PKCS#12 document sealing. Both are in the catalogue - deploy both for a weekend and keep the one your team likes. ## Documenso URL: https://deployable.sh/apps/documenso/ Category: Business Apps Upstream: Documenso, https://documenso.com Template source: https://github.com/deployable-sh/stacks/tree/main/documenso Documenso is the venture-grade open-source e-signature product: a signing experience recipients do not need explaining, teams and templates for the senders, an API for automation - and signed PDFs sealed with a real PKCS#12 certificate, so documents carry cryptographic proof, not just an audit log. The deployment is stateless: one container on a managed Postgres, with the signing certificate supplied as base64 in env (self-signed is explicitly supported - the README has the three openssl commands). NEXT_PUBLIC_* vars are runtime-injected, so the official image deploys behind any domain without rebuilds. Hosted Documenso runs $25-40/month with the heavier features in higher tiers; DocuSign charges per envelope. Self-hosted is unlimited documents on a $25 plan - the AGPL edition does not gate signing. Footprint: 3 GiB RAM, 5 GB disk, 2 service(s). Miget sizing: Hobby 4 GiB plan at $25/mo; Professional 4 GiB at $43/mo. Managed-service comparison (June 2026): DocuSign Standard ~$30/mo; PandaDoc Starter ~$19/mo; Documenso Cloud Teams ~$40/mo. FAQ: Q: Why does it need a certificate, and is self-signed really OK? A: The cert seals signed PDFs so the signature verifies cryptographically inside the document. Documenso explicitly supports self-signed certs (three openssl commands, base64 into env) - the seal proves integrity either way. Generate it once and keep it: old documents verify against the cert that sealed them. Q: How does pricing compare to DocuSign and PandaDoc? A: DocuSign Standard is $30/user/month with 100 envelopes/year; PandaDoc Starter $19/seat with 110 documents/year. This stack is $25/month total, unlimited documents and users - and Documenso’s own cloud Teams tier is $40/month, so even first-party hosting costs more than running it here. Q: Documenso or DocuSeal? A: Documenso for the recipient-facing polish, teams, and cert-sealed PDFs; DocuSeal for the lighter footprint and fastest setup. Both are AGPL with un-gated signing - the honest answer is taste, and the catalogue ships both. ## Typebot URL: https://deployable.sh/apps/typebot/ Category: Business Apps Upstream: Typebot, https://typebot.io Template source: https://github.com/deployable-sh/stacks/tree/main/typebot Typeform proved that conversational beats static for completion rates, then priced it like a luxury: $29/month buys 100 responses. Typebot is the open-source version of the idea - a drag-and-drop builder for chat-style forms and bots, with logic, variables, integrations, and result analytics - and it was a top-10 template on Railway by deploy count. The architecture is template-friendly: two stateless Next.js apps (the builder where you design, the viewer respondents see) on one managed Postgres, each on its own domain with PORT honored - no proxies. The builder runs migrations; the pair redeploys cleanly. Self-hosted, your ADMIN_EMAIL account gets the unlimited plan: unlimited typebots, chats, and seats. Even Typebot’s own cloud charges $39/month for 2,000 chats. Footprint: 2.5 GiB RAM, 5 GB disk, 3 service(s). Miget sizing: Hobby 4 GiB plan at $25/mo; Professional 4 GiB at $43/mo. Managed-service comparison (June 2026): Typeform Basic ~$29/mo; Typebot Cloud Starter ~$39/mo. FAQ: Q: How does this compare to Typeform pricing? A: Typeform Basic is $29/month for 100 responses - a single popular form blows through that in a day. Self-hosted Typebot has no response meter at all: $25/month infrastructure, unlimited chats, unlimited seats. Q: Why two apps and two domains? A: Separation of concerns upstream: the builder is your internal workspace; the viewer is the public-facing bot runtime you embed on sites. Both honor PORT, so each simply gets its own domain - no proxy sidecars needed. Q: What does the FSL license mean for me? A: Free for internal use and client work; the restriction is reselling access to your instance as a hosted service. Each FSL release converts to Apache-2.0 after two years. For the standard "our company’s forms" use case, nothing changes. Q: How do logins work without passwords? A: Magic links by email (point SMTP at a real relay - or at the mailpit template during testing) or OAuth (GitHub/Google/Azure AD vars). Set DISABLE_SIGNUP=true once your team is aboard. ## Twenty CRM URL: https://deployable.sh/apps/twenty/ Category: Business Apps Upstream: Twenty, https://twenty.com Template source: https://github.com/deployable-sh/stacks/tree/main/twenty CRM pricing is the per-seat genre at its purest: Attio runs $29-36 per user, Pipedrive $14-24, HubSpot looks cheap until contact tiers bite - and every new hire is a new line item. Twenty is the open-source reset: a CRM with a genuinely modern data model (custom objects and fields like a database, not a form builder), pipelines, notes, tasks, email sync, and workflows. Since v2.1 upstream calls self-hosting production-ready, and the shape fits this catalogue perfectly: server and worker from one image on a managed Postgres (stock Postgres 16 - the old custom-image era is over), with a noeviction Valkey for the BullMQ queue that drives email sync, imports, and workflows. One classic gotcha is handled loudly: SERVER_URL must exactly match the public URL - the README says so twice, because it is the number-one self-hosting support thread upstream. Footprint: 3.3 GiB RAM, 10 GB disk, 4 service(s). Miget sizing: Hobby 4 GiB plan at $25/mo; Professional 4 GiB at $43/mo. Managed-service comparison (June 2026): Attio Plus ~$290/mo; Pipedrive Lite ~$140/mo; HubSpot Starter ~$150/mo. FAQ: Q: How does the cost compare to Attio or Pipedrive? A: A 10-person team pays $290-360/month on Attio or $140-240 on Pipedrive, forever, growing with headcount. Twenty here is $25/month flat with unlimited seats - the crossover is at the second user. Q: Is self-hosted Twenty actually production-ready? A: Upstream marked it so with v2.1 (April 2026) and ships an official compose this template mirrors: same-image server/worker split, stock Postgres, noeviction Redis. The earlier custom-Postgres-image era is over. Q: What is the SERVER_URL warning about? A: Twenty derives auth callbacks and CORS from SERVER_URL, so any mismatch with the real public URL produces opaque 403s - it is the most common self-hosting issue upstream. Set it to the exact https domain and the problem class disappears. Q: Does the AGPL license matter for my sales data? A: No - AGPL governs the software, not your data. A few enterprise-marked files (SSO and similar) are commercially licensed upstream, but the CRM you deploy here is the full product for everyday use. ## Kestra URL: https://deployable.sh/apps/kestra/ Category: Automation & Jobs Upstream: Kestra, https://kestra.io Template source: https://github.com/deployable-sh/stacks/tree/main/kestra Every Airflow deployment eventually asks the same question: how do DAG files get onto the workers? On a PaaS, that question has no good answer - which is why this catalogue ships Kestra instead. Flows are declarative YAML, authored and versioned in the UI, stored in Postgres: there is nothing to deploy when you add a workflow. One JVM container does it all (UI, API, scheduler, executor, worker in standalone mode), with both the queue and the repository on the managed Postgres - no Redis, no Celery, no fleet of components. Hundreds of plugins cover HTTP, SQL, dbt, files, and notifications; schedules, webhooks, and flow-dependency triggers come built in. The platform constraint is handled in the template, not discovered later: script tasks default to Kestra’s Docker runner, which needs a socket - this template pins the PROCESS runner as the plugin default so Python/Shell tasks run in-container. Footprint: 4 GiB RAM, 15 GB disk, 2 service(s). Miget sizing: Hobby 4 GiB plan at $25/mo; Professional 4 GiB at $43/mo. Managed-service comparison (June 2026): Astronomer Developer (managed Airflow) ~$255/mo. FAQ: Q: Why Kestra instead of Airflow? A: On a PaaS, Airflow’s DAG-file deployment story has no good answer - the stock image ships empty with no ingest mechanism, so a template would deploy an orchestrator you cannot feed. Kestra flows live in the database and are authored in the UI; the problem simply does not exist. (If you are deeply Airflow-invested, Astronomer’s managed offering is the honest recommendation.) Q: What does managed orchestration cost by comparison? A: Astronomer (managed Airflow) starts around $0.35/hour per deployment - roughly $255/month always-on, before workers. Kestra Cloud is usage-priced. This stack is $49/month flat with the full open-source feature set. Q: Can my flows run Python scripts? A: Yes - the template pre-configures the PROCESS task runner (the Docker runner needs a socket the platform does not expose), so scripts execute inside the Kestra container. Bake extra toolchains into a derived image, or call services in your project over HTTP for heavier work. Q: How does Kestra compare to n8n in this catalogue? A: n8n is integration automation (connect SaaS apps, react to events) with a visual editor; Kestra is data/engineering orchestration (pipelines, dependencies, retries, backfills) with declarative YAML. Plenty of teams run both - they meet different needs. ## FileBrowser URL: https://deployable.sh/apps/filebrowser/ Category: Object Storage Upstream: FileBrowser, https://filebrowser.org Template source: https://github.com/deployable-sh/stacks/tree/main/filebrowser Sometimes the requirement is exactly this small: a place to put files, a UI to browse them, and a link to share one. FileBrowser is that tool with no ceremony - a single Apache-2.0 Go binary with previews, an editor, per-user scopes, and public share links, running non-root with a built-in healthcheck. This template is the catalogue’s simplest stateful deploy: one container, a files volume, an admin login from env. Released near-daily upstream and small enough that the $5 plan carries it with room to spare. Scope honesty: it shares and serves files, it does not host websites (Miget’s native static hosting does that) and it is volume-backed by design - the S3-backed manager lane belongs to Filestash. Footprint: 256 MiB RAM, 9 GB disk, 1 service(s). Miget sizing: Hobby 512 MiB plan at $5/mo; Professional 2 GiB at $22/mo. FAQ: Q: FileBrowser or Filestash - which one? A: FileBrowser for volume-backed personal/team file sharing with the least setup. Filestash when the backend should be S3 (Miget Buckets). For serving a whole website, use Miget’s native static hosting. Different jobs, different tools. Q: Can people without accounts receive files? A: Yes - share links are public URLs (optionally time-limited) served from your domain. For inbound uploads from outsiders, SFTPGo’s share-upload links are the stronger tool. Q: Is it safe to expose? A: It sits behind its own auth over the platform’s TLS, runs non-root, and has no system access beyond its volumes. Use a strong admin password and scoped users for anything shared. ## Roundcube URL: https://deployable.sh/apps/roundcube/ Category: Email & Newsletters Upstream: Roundcube, https://roundcube.net Template source: https://github.com/deployable-sh/stacks/tree/main/roundcube A webmail client is the honest way to self-host email on a PaaS: the mail server stays wherever deliverability lives (Fastmail, Gmail, your VPS Dovecot), and you own the interface - the part that holds your sessions, contacts, and habits. Roundcube has been the standard for two decades: folders, search, filters, address book, responsive Elastic skin. This template runs it stateless on a managed Postgres (settings, contacts, caches), behind a thin proxy. Two variables point it at your provider; users log in with their own mailbox credentials. The deliberately absent piece is stated, not hidden: no SMTP server ships here, because nothing on shared cloud IPs can credibly deliver port-25 mail. Client here, relay where it belongs - the same honest split as the listmonk template. Footprint: 1.6 GiB RAM, 5 GB disk, 3 service(s). Miget sizing: Hobby 2 GiB plan at $13/mo; Professional 2 GiB at $22/mo. FAQ: Q: Does this replace Fastmail or Google Workspace? A: It replaces their web INTERFACE, not their servers: you keep paying ~$5-7/user for the mailbox and deliverability, while the UI, session data, and contacts live on your infrastructure. Full mail-server self-hosting needs port 25 and IP reputation no shared platform can offer - this split is the honest one. Q: Can different users connect different providers? A: The template sets one default IMAP host - right for a team on one provider. Multi-host setups go in a mounted config; for a true multi-account aggregator UX, Cypht is the upstream alternative worth a look. Q: Does Gmail work? A: Yes, with an app password (or OAuth via plugin configuration): imap.gmail.com over ssl:// and smtp.gmail.com over tls://. Workspace accounts behave the same. ## TEI Embeddings URL: https://deployable.sh/apps/tei/ Category: LLM Infrastructure Upstream: Text Embeddings Inference (Hugging Face), https://github.com/huggingface/text-embeddings-inference Template source: https://github.com/deployable-sh/stacks/tree/main/tei Embeddings are the quiet recurring cost of RAG: every document chunk and every query goes through the API meter, forever. Small open models ended that trade - bge-small at 384 dimensions handles real retrieval workloads, and Hugging Face’s TEI serves it from CPU in about half a gigabyte of RAM, no GPU anywhere. TEI is a Rust server with an OpenAI-compatible /v1/embeddings endpoint, so existing clients just change the base URL. It is internal-only by design (no built-in auth): apps in your project call http://tei:5000 over the private network. This completes the catalogue’s self-contained RAG loop: embed with tei, store in qdrant or chromadb, generate via the litellm gateway, trace in langfuse or phoenix - with the embedding leg now costing exactly $7/month flat. Footprint: 1 GiB RAM, 2 GB disk, 1 service(s). Miget sizing: Hobby 1 GiB plan at $7/mo; Professional 2 GiB at $22/mo. FAQ: Q: How good is bge-small compared to API embeddings? A: For typical RAG retrieval it is competitive with commercial small embeddings - strong MTEB scores at 384 dimensions, which also halves your vector storage versus 768+ dim models. Test with your corpus; swapping MODEL_ID is one variable. Q: What does this actually save? A: API embeddings meter every chunk at index time and every query forever, and re-indexing a corpus repeats the whole bill. Self-hosted, the marginal cost of embedding is zero - re-index freely, embed logs, embed everything. Q: Why is it internal-only? A: TEI ships no authentication, so it must not face the internet. In-project apps reach tei:5000 over the private network - the same posture as the qdrant and chromadb templates it pairs with. Q: Can it rerank too? A: Yes - TEI serves reranker models on /rerank. Run a second instance with a reranker MODEL_ID (e.g. bge-reranker variants) and call it after retrieval for a meaningful quality lift. ## Phoenix URL: https://deployable.sh/apps/phoenix/ Category: LLM Infrastructure Upstream: Arize Phoenix, https://phoenix.arize.com Template source: https://github.com/deployable-sh/stacks/tree/main/phoenix Not every team needs a six-service observability platform on day one. Phoenix puts LLM tracing, evaluations, datasets, and a prompt playground in a single container with SQLite on a volume - up in seconds, OpenTelemetry-native, with auto-instrumentation for LangChain, LlamaIndex, and raw OpenAI clients. In this catalogue it is the deliberate counterpart to langfuse: start here when you want traces this afternoon; graduate to the full stack when volume and team workflows demand it. Both speak OTel, so your instrumentation survives the move. Auth is on, telemetry is off, and the secret is one variable. Arize’s hosted product (AX) starts at $50/month past the free tier - this is $13 with your data on your volume. Footprint: 2 GiB RAM, 10 GB disk, 1 service(s). Miget sizing: Hobby 2 GiB plan at $13/mo; Professional 2 GiB at $22/mo. Managed-service comparison (June 2026): Arize AX Pro ~$50/mo; LangSmith Plus ~$39/mo. FAQ: Q: Phoenix or Langfuse - this catalogue has both? A: Deliberately: Phoenix is the one-container start (tracing + evals today, minimal ops), Langfuse the full platform (workers, ClickHouse-scale ingestion, prompt management workflows). Both ingest OpenTelemetry, so starting with Phoenix costs you nothing if you graduate. Q: How do traces get in? A: OTLP/HTTP to http://phoenix:5000/v1/traces or gRPC to phoenix:4317 from apps in the project - or use Phoenix’s SDKs, which auto-instrument LangChain, LlamaIndex, and OpenAI-compatible clients (including calls through the litellm template) in a couple of lines. Q: What does the ELv2 license mean for me? A: Self-hosting Phoenix for your own products and teams is unrestricted. The Elastic License only forbids offering Phoenix itself as a managed service to third parties - the standard source-available trade, flagged here so nothing surprises you. ## Filestash URL: https://deployable.sh/apps/filestash/ Category: Object Storage Upstream: Filestash, https://www.filestash.app Template source: https://github.com/deployable-sh/stacks/tree/main/filestash Buckets are where files live; Filestash is how humans use them: a fast web manager with previews (images, video, office documents), editing, and share links - over any S3-compatible backend, with path-style addressing always forced so Miget Buckets just work. The admin console pre-configures the connection (endpoint + keys, optionally pre-filled) so users land directly in the bucket. AGPL, very actively maintained, and famously light - the docs quote 128 MB. It completes a three-tool storage lane with distinct jobs: filebrowser (volume-backed simplicity), filestash (the bucket UI), sftpgo (the upload portal). Footprint: 640 MiB RAM, 1 GB disk, 2 service(s). Miget sizing: Hobby 1 GiB plan at $7/mo; Professional 2 GiB at $22/mo. FAQ: Q: How does this relate to Miget’s own bucket UI? A: The platform UI is for operating buckets; Filestash is for the humans who use the files daily - previews, editing, and share links you can hand to a client. Same bucket underneath, different audience. Q: Filestash, FileBrowser, or SFTPGo? A: Filestash when the data lives in buckets and people need a rich UI over it. FileBrowser for the simplest volume-backed sharing. SFTPGo when outsiders must upload into buckets (share-upload links, per-user prefixes, SFTP). All three are $5-7/month. Q: What is the first-deploy checklist? A: Visit /admin immediately (the first visitor sets the admin password), add the S3 connection with your bucket endpoint and keys, and set APPLICATION_URL to your domain. Two minutes, documented in the README. ## SFTPGo URL: https://deployable.sh/apps/sftpgo/ Category: Object Storage Upstream: SFTPGo, https://sftpgo.com Template source: https://github.com/deployable-sh/stacks/tree/main/sftpgo Every agency and consultancy has the same recurring problem: getting large files FROM clients. SFTPGo solves it elegantly - create a share-upload link (password, expiry, usage caps) and the client uploads straight into a Miget Bucket folder, no account, no WeTransfer. Underneath is a serious multi-protocol file server: each user’s filesystem can BE an S3 bucket (custom endpoint, forced path-style, per-user key prefix to confine them to a folder), fronted by a web client, and optionally real SFTP over a custom TCP port or WebDAV. A single AGPL Go binary at ~50 MB, with a proper admin UI and REST API for automation - the smallest template in the catalogue that replaces an entire category of file-exchange SaaS. Footprint: 512 MiB RAM, 6 GB disk, 1 service(s). Miget sizing: Hobby 512 MiB plan at $5/mo; Professional 2 GiB at $22/mo. FAQ: Q: How do client uploads work without accounts? A: Create a user mapped to a bucket prefix, then issue a write-enabled share link with a password and expiry. The client opens the link in a browser and drops files - they land in your bucket folder, and the link can self-expire after N uses. Q: Can I offer real SFTP? A: Yes - SFTPGo listens on :2022 inside the project; add a public custom TCP port on the app and map it, and classic SFTP clients connect with per-user credentials while reading/writing the same buckets. Q: How is each user wired to a Miget Bucket? A: In the admin UI: filesystem provider "AWS S3 (compatible)", bucket name, the bucket’s S3 endpoint, keys, force-path-style on, and an optional key prefix to confine the user to a subfolder. Scriptable via the REST API for onboarding automation. ## MariaDB Galera URL: https://deployable.sh/apps/mariadb-galera/ Category: Databases Upstream: MariaDB 11.8 LTS + Galera, https://mariadb.org Template source: https://github.com/deployable-sh/stacks/tree/main/mariadb-galera MySQL-family high availability got harder to ship in 2025 when Broadcom paywalled the Bitnami images everyone’s tutorials used. The good news, verified by actually running clusters: the OFFICIAL mariadb image carries the Galera library, and a 3-node multi-primary cluster forms from pure command-line flags plus one env var. Galera is synchronous: every node accepts writes, every commit lands on the quorum, and a node loss costs availability nothing. The traps are operational, and this template handles each one found in testing - the bootstrap flag fires only on a genuinely first boot (a permanent flag crash-loops on restart), stop_grace_period is 2 minutes (the 10-second default SIGKILLs mariadbd and poisons cluster state), and the cold-start recovery procedure is documented rather than discovered at 3am. An app database and user replicate to all nodes at bootstrap. Apps connect to any node - list all three for driver-level failover. Footprint: 3 GiB RAM, 15 GB disk, 3 service(s). Miget sizing: Hobby 4 GiB plan at $25/mo; Professional 4 GiB at $43/mo. FAQ: Q: Why not the managed MySQL? A: The managed MySQL is the right default for a single instance. This template exists for the HA case - synchronous multi-primary across three nodes - which managed single-instance offerings do not provide. Different reliability class, same project network. Q: What happened to the Bitnami images everyone used? A: Broadcom moved Bitnami to paid “Secure Images” in late 2025; the free mariadb-galera images are frozen without security updates. This template needs none of that: the official mariadb image has shipped the Galera library all along, configured via flags. Q: What does the bootstrap wrapper actually solve? A: Galera’s classic foot-gun: --wsrep-new-cluster must run exactly once, on the first node’s first boot. Left in the command permanently, the safe_to_bootstrap guard crash-loops the node on every restart - verified by testing. The wrapper checks for grastate.dat and adds the flag only when the datadir is genuinely new. Q: What if the whole cluster stops uncleanly? A: Galera refuses to guess which node has the newest data - by design. The README gives the two-step recovery (pick the highest-seqno node, flip safe_to_bootstrap, start it first). It is a documented 2-minute procedure, not an outage mystery. ## Minecraft Server URL: https://deployable.sh/apps/minecraft/ Category: Game Servers Upstream: itzg/minecraft-server, https://docker-minecraft-server.readthedocs.io Template source: https://github.com/deployable-sh/stacks/tree/main/minecraft The itzg image is the most-deployed game server container in existence for a reason: set TYPE and VERSION, and it fetches and runs Paper, Fabric, Forge, or Vanilla - mods, datapacks, and world on a persistent volume, console via rcon. Game hosting traditionally prices by player slots and tiers RAM behind upsells. A flat compute plan inverts that: 2 GB of Paper heap comfortably carries a 10-20 player community for $25/month, and raising MEMORY plus the plan is the entire scaling procedure. Two honest notes: Mojang’s EULA is yours to accept (EULA=TRUE is deliberately not pre-set), and Minecraft speaks raw TCP - after deploy you add a public custom TCP port to the app and hand players that address. No HTTP anywhere. Footprint: 3 GiB RAM, 10 GB disk, 1 service(s). Miget sizing: Hobby 4 GiB plan at $25/mo; Professional 4 GiB at $43/mo. FAQ: Q: How do players connect if the platform is HTTP-first? A: Miget supports custom public TCP ports: add one mapped to 25565 in the app settings and share host:port. The HTTP-on-5000 convention simply does not apply - this template is the catalogue’s first pure-TCP citizen. Q: How many players does this run? A: Paper with a 2 GB heap typically carries 10-20 concurrent players; vanilla less, aggressively-optimized Paper more. Modpacks change the math entirely - size heap to the pack’s recommendation and the plan above it. Q: Why must I set EULA myself? A: Mojang’s EULA binds the server operator - you. The image (correctly) refuses to start until EULA=TRUE, and this template (correctly) refuses to accept it on your behalf. One variable, informed consent. Q: Can I run mods and plugins? A: Yes - drop plugins/mods into the volume (or use the image’s MODRINTH/CURSEFORGE env helpers), set TYPE to match the loader, restart. Everything persists across redeploys. ## Factorio Server URL: https://deployable.sh/apps/factorio/ Category: Game Servers Upstream: factoriotools/factorio, https://github.com/factoriotools/factorio-docker Template source: https://github.com/deployable-sh/stacks/tree/main/factorio Factorio multiplayer deserves a server that never sleeps with someone’s laptop. The community-standard image runs the official headless server: a map generates on first boot, the latest save loads ever after, autosaves roll on the volume, and mods can update themselves on restart. It is one of the lightest game servers there is - 2 GB of RAM carries factories far past the point where the real bottleneck is your friends’ ability to agree on bus layouts. $13/month flat, no slot pricing. Factorio speaks UDP: after deploy, add a public custom UDP port to the app and share host:port. Server name, password, and admins live in server-settings.json on the volume. Footprint: 2 GiB RAM, 5 GB disk, 1 service(s). Miget sizing: Hobby 2 GiB plan at $13/mo; Professional 2 GiB at $22/mo. FAQ: Q: How do players connect? A: Add a custom public UDP port on the app (internal 34197) and share host:port - players use "Connect to address". For the in-game public server browser, set visibility and your factorio.com token in server-settings.json. Q: How do saves and mods work across redeploys? A: Everything lives on the /factorio volume: saves, mods, settings. Redeploys load the latest autosave; UPDATE_MODS_ON_START=true keeps mods current with the server version. Q: Why is this cheaper than the Minecraft template? A: No JVM: Factorio’s headless server is lean native code. 2 GiB and one UDP port is genuinely the whole footprint until your factory reaches megabase scale - at which point the upgrade is CPU, and you will know. ## Chatwoot URL: https://deployable.sh/apps/chatwoot/ Category: Business Apps Upstream: Chatwoot (CE), https://www.chatwoot.com Template source: https://github.com/deployable-sh/stacks/tree/main/chatwoot Support tooling prices per agent, which punishes exactly the team you want answering customers. Chatwoot is the open-source counter: a shared inbox across live chat, email, and social channels, with assignment rules, canned responses, automations, and a help center - and this template ships the pure-MIT community-edition image (v4-ce, no enterprise code). The topology is the full production shape: Rails web (live chat rides websockets at /cable), a Sidekiq worker, an idempotent migrate sidecar, a noeviction Valkey for the queues - and a pgvector Postgres container, because Chatwoot v4 hard-requires the extension (its AI features embed conversations). A 5-agent team pays $145-275/month at Intercom or Zendesk before AI add-ons. This stack is $25/month with unlimited agents, and a noisy month costs nothing extra. Footprint: 3.8 GiB RAM, 15 GB disk, 5 service(s). Miget sizing: Hobby 4 GiB plan at $25/mo; Professional 4 GiB at $43/mo. Managed-service comparison (June 2026): Intercom Essential ~$145/mo; Zendesk Suite Team ~$275/mo; Chatwoot Cloud Startups ~$95/mo. FAQ: Q: What does this save vs Intercom or Zendesk? A: Intercom Essential is $29/seat/month (plus $0.99 per AI resolution); Zendesk Suite Team is $55/agent. Five agents cost $145-275/month before add-ons - versus $25 flat here, agents uncounted. Chatwoot’s own cloud is $19/agent, so even first-party hosting meters what this does not. Q: Why does the template run its own Postgres? A: Chatwoot v4 requires the pgvector extension (migrations fail without it), which managed Postgres offerings do not ship - so the template runs the pgvector image as a private container. Everything else about the stack uses the standard catalogue patterns. Q: How does the live chat widget work? A: Create a website inbox and embed the snippet; visitor chats arrive over websockets at /cable on your domain, which the platform ingress passes through. FRONTEND_URL must be your real https domain - the widget embeds it. Q: Is the CE image missing anything important? A: The v4-ce tag strips the commercial enterprise directory (SLA policies, audit logs, some AI features). The core support workflow - inboxes, channels, automations, help center, reports - is fully there, under plain MIT. ## Superset URL: https://deployable.sh/apps/superset/ Category: Monitoring & Analytics Upstream: Apache Superset, https://superset.apache.org Template source: https://github.com/deployable-sh/stacks/tree/main/superset Superset is what BI looks like when a data team builds it for themselves: a no-code chart builder with forty-plus visualization types, dashboards with filters and drill-downs, SQL Lab for the analysts, and scheduled alerts and reports - Apache-2.0, no feature meter, no seat meter. This template ships the real production shape: gunicorn app, Celery worker and beat for async queries and scheduled reports, an idempotent init sidecar (migrations + admin bootstrap), a noeviction Valkey, and the managed Postgres for metadata. The dict-style config Superset requires is baked the officially documented way - a small superset_config.py reading everything simple from env. Preset (the hosted Superset) starts at $100/month base plus $6 per user. This stack is $49/month with users uncounted - and your warehouses stay on the project network. Footprint: 5.3 GiB RAM, 10 GB disk, 6 service(s). Miget sizing: Hobby 8 GiB plan at $49/mo; Professional 8 GiB at $85/mo. Managed-service comparison (June 2026): Preset Professional ~$300/mo; Metabase Cloud Starter ~$100/mo. FAQ: Q: Superset or Metabase - the catalogue has both? A: Metabase for self-serve simplicity (marketing asks it questions); Superset for data-team power - SQL Lab, fine-grained chart control, dashboards-as-product, alerts. Both run on flat plans here; many orgs genuinely use both. Q: How does the cost compare to Preset or Tableau-class BI? A: Preset Professional is $20/user/month on top of a $100 Starter base; Tableau-class tools run $70+/user. A 15-person analytics audience costs $300-1,000+/month hosted - versus $49 flat here, with the same Superset. Q: What can it connect to in my project? A: Everything with a SQLAlchemy driver, by service name: clickhouse (ch-1:8123), timescaledb, mariadb-galera, mssql, the managed Postgres your apps use. In-project connections never leave the private network. Q: Why does the template bake a config file? A: Superset’s Celery and cache settings are Python dicts that env vars cannot express - the upstream-documented pattern is exactly this baked superset_config.py with SUPERSET_CONFIG_PATH. Simple values still come from env; you should never need to edit it. ## Prefect URL: https://deployable.sh/apps/prefect/ Category: Automation & Jobs Upstream: Prefect 3, https://www.prefect.io Template source: https://github.com/deployable-sh/stacks/tree/main/prefect Prefect’s pitch is that orchestration should feel like Python: decorate a function, deploy it, and the server handles schedules, retries, state, and a clean UI of every run. No DAG files, no DSL - flows are code in your repo. The architecture is PaaS-shaped by design: this template runs the server (UI + API + scheduler, basic-auth protected) on a managed Postgres, while WORKERS - the processes that execute your flow code - run as separate apps polling outbound, exactly like this catalogue’s CI runners. No ingress to workers, scale them per workload. Prefect Cloud’s team plans start around $100/month; the open-source server is the full orchestration engine at $13. Footprint: 2 GiB RAM, 5 GB disk, 2 service(s). Miget sizing: Hobby 2 GiB plan at $13/mo; Professional 2 GiB at $22/mo. Managed-service comparison (June 2026): Prefect Cloud Starter ~$100/mo. FAQ: Q: Kestra or Prefect - the catalogue has both? A: By language of thought: Kestra is declarative YAML authored in the UI (zero code-deployment story); Prefect is Python in your repo with the ergonomics Python people expect. Data teams split on this honestly - both are flat-priced here, so taste can decide. Q: Where does my flow code actually run? A: In workers you deploy as separate apps: an image built from prefecthq/prefect:3-latest plus your code, started with prefect worker start against http://prefect:5000/api and the shared auth string. Workers poll outbound - no ports, no ingress, scale horizontally. Q: How does this compare to Prefect Cloud? A: Cloud’s free Hobby tier is genuinely useful (2 users, 5 deployments); paid starts around $100/month. The self-hosted server has no user or deployment caps - Cloud adds their ops, RBAC, and push-work pools on top of the same engine. ## Logto URL: https://deployable.sh/apps/logto/ Category: Auth & API Gateway Upstream: Logto, https://logto.io Template source: https://github.com/deployable-sh/stacks/tree/main/logto What developers actually liked about Auth0 was the first hour: drop-in sign-in pages, a quickstart per framework, social logins in minutes. Logto rebuilds that experience as MPL-2.0 open source - pre-built auth flows, organizations, MFA, and SDKs for every stack - without the per-MAU cliff that follows. One container serves two origins (the user-facing auth endpoint and your admin console), so the template gives each its own domain via thin proxies - the same pattern as Saleor. Database seeding is idempotent and runs on every boot; the managed Postgres is wired automatically. This completes a four-IdP identity lane with honest positioning: Logto for the Auth0-style developer experience, Zitadel for B2B multi-tenancy, authentik for flow design, Keycloak for protocol depth. Footprint: 2 GiB RAM, 5 GB disk, 4 service(s). Miget sizing: Hobby 2 GiB plan at $13/mo; Professional 2 GiB at $22/mo. Managed-service comparison (June 2026): Auth0 Essentials (B2C) ~$70/mo; Clerk Pro ~$25/mo. FAQ: Q: How does Logto compare to Auth0 pricing? A: Auth0’s free tier now covers 25k MAU, but paid starts at $35-70/month for the first thousand-MAU steps and climbs steeply. Logto here is $25/month with no user counting - and the developer experience (hosted pages, SDK quickstarts) is the part it cloned best. Q: Why does it need two domains? A: Logto deliberately separates the user-facing auth origin from the admin console origin - good security hygiene. Each platform app exposes one public port, so two thin proxies give each origin its own domain; ENDPOINT and ADMIN_ENDPOINT tell Logto which is which. Q: Which IdP in this catalogue should I pick? A: Logto if you want Auth0-style drop-in auth for a product fast. Zitadel for passkeys-first B2B multi-tenancy. authentik for visually-designed flows across many internal apps. Keycloak for maximum protocol surface. They are $13-25/month each - trying two is an afternoon. ## LiveKit URL: https://deployable.sh/apps/livekit/ Category: Voice & Realtime Upstream: LiveKit, https://livekit.io Template source: https://github.com/deployable-sh/stacks/tree/main/livekit LiveKit became the substrate of the voice AI wave: a single Apache-2.0 Go binary doing WebRTC rooms, tracks, and selective forwarding, with the Agents framework ecosystem on top. Self-hosting it historically meant a 10,000-port UDP range - hostile to any platform. This template uses the config that fixes that: ALL media muxes over one UDP port (7882), with one TCP fallback (7881) and the websocket signal on :5000 behind the ordinary HTTPS ingress. Two custom public ports, same numbers inside and out, and WebRTC works. Pair it with the livekit-agents template and you have a complete self-hosted voice-agent platform: this server moves the audio; the agent worker brings ElevenLabs, Deepgram, and your LLM gateway. Footprint: 1 GiB RAM, 0 GB disk, 1 service(s). Miget sizing: Hobby 1 GiB plan at $7/mo; Professional 2 GiB at $22/mo. FAQ: Q: How does WebRTC work on an HTTP-first platform? A: Three ports, deliberately: the signal is a websocket on the normal HTTPS domain, and media rides ONE muxed UDP port (7882) with a TCP fallback (7881) - both exposed as custom public ports with matching numbers, since ICE advertises them. Clients on hostile networks fall back to TCP automatically. Q: Why self-host instead of LiveKit Cloud? A: Cloud is excellent and usage-priced - the honest default for spiky workloads. Self-hosting wins for always-on voice agents (predictable cost), data locality (audio never transits a third party), and pairing with the in-project agent worker at LAN latency. Q: What do clients connect with? A: Access tokens minted from your API key/secret by any LiveKit server SDK - one function call in your backend. The client SDKs (web, mobile, Unity) then connect to wss://your-domain and join rooms. ## LiveKit Agents URL: https://deployable.sh/apps/livekit-agents/ Category: Voice & Realtime (experimental) Upstream: LiveKit Agents (Python starter), https://docs.livekit.io/agents/ Template source: https://github.com/deployable-sh/stacks/tree/main/livekit-agents Voice agents stopped being demos: support lines, intake calls, tutoring, companions. The LiveKit Agents framework is what most of them run on - a Python worker that joins rooms, listens via Deepgram, thinks via any OpenAI-compatible LLM, and speaks via ElevenLabs. The deployment shape could not be friendlier to a PaaS: the worker connects OUTBOUND to your LiveKit server and receives jobs - no ingress, no public port. CPU is plenty; only voice-activity detection runs locally, everything heavy is an API call. This template builds LiveKit’s official Python starter as a working baseline and is marked experimental for an honest reason: a real product forks the starter to define its own agent - the template’s build context is the line you change. Footprint: 2 GiB RAM, 0 GB disk, 1 service(s). Miget sizing: Hobby 2 GiB plan at $13/mo; Professional 2 GiB at $22/mo. FAQ: Q: What does a complete self-hosted voice stack look like here? A: livekit (the WebRTC server) + this worker + litellm (LLM gateway with budgets) in one project. Audio flows through your server, the agent reasons through your gateway, and the only external spend is the STT/TTS/LLM APIs you chose. Q: Why is it experimental? A: Because the starter agent is a baseline, not your product: real deployments fork agent-starter-python, change the prompt/tools/pipeline, and point this template’s build context at the fork. The infrastructure shape is solid; the agent code is meant to be yours. Q: Can it use voices other than ElevenLabs? A: Yes - the framework has plugins for Cartesia, OpenAI TTS, PlayHT and more; swap the pipeline in your fork and set the matching key. Same for STT and LLM legs. ## useSend URL: https://deployable.sh/apps/usesend/ Category: Email & Newsletters Upstream: useSend (formerly Unsend), https://usesend.com Template source: https://github.com/deployable-sh/stacks/tree/main/usesend Resend made transactional email pleasant: clean API, dashboard, domains, analytics. useSend rebuilds that experience as AGPL open source - with delivery handled by YOUR AWS SES, which is the architecturally honest choice (SES owns IP reputation at ~$0.10 per 1,000 emails; you own the platform, templates, contacts, and data). The stack is catalogue-standard: the Next.js app behind a thin proxy, BullMQ sends queued in a noeviction Valkey, everything durable in the managed Postgres. Migrations run on start. The honest prerequisites are listed, not discovered: SES production access and a GitHub OAuth app (useSend’s login provider). Once those exist, you have Resend’s workflow at SES postage prices - 100k emails costs ~$10 in delivery, not a tier upgrade. Footprint: 2.3 GiB RAM, 5 GB disk, 4 service(s). Miget sizing: Hobby 4 GiB plan at $25/mo; Professional 4 GiB at $43/mo. Managed-service comparison (June 2026): Resend Pro ~$20/mo; Postmark Basic ~$15/mo. FAQ: Q: How does the cost compare to Resend? A: Resend Pro is $20/month for 50k emails, $35 for 100k. useSend is $25/month infrastructure plus SES postage (~$0.10/1k): 100k emails ≈ $35 total, 500k ≈ $75 - and the curve flattens where Resend’s tiers climb. Below ~50k/month, Resend’s simplicity honestly wins; above it, owning the platform does. Q: Why is AWS SES required rather than any SMTP? A: useSend is built around SES APIs and SNS delivery webhooks (bounces, complaints, opens) - that integration is what makes the analytics real. It is the same architecture Resend itself runs on; you are just holding the SES account. Q: useSend or listmonk - the catalogue has both? A: useSend for the Resend-shaped job: transactional API + product emails + light campaigns, developer-first. listmonk for serious newsletter/list management at scale (segmentation, double opt-in machinery). They share the SES-underneath philosophy and coexist happily. ## Cognee URL: https://deployable.sh/apps/cognee/ Category: LLM Infrastructure Upstream: Cognee, https://www.cognee.ai Template source: https://github.com/deployable-sh/stacks/tree/main/cognee Agents without memory re-learn your world every session. Cognee is the maintained open-source answer (Apache-2.0, 17k+ stars, releases this month): ingest documents and conversations, "cognify" them into a knowledge graph plus vector index, and query the result as long-term memory over a clean API. The engineering taste shows in the defaults: SQLite, LanceDB, and Kuzu all run in-process - one container, one volume, no sidecar fleet. Every layer has a scale-out path via env (Postgres, the catalogue’s qdrant, Neo4j) when you genuinely need it. It is API-first (Swagger at /docs; the upstream UI is a separate work-in-progress) and slots into the catalogue’s agent lane: route extraction through the litellm gateway, and give agent-box or OpenClaw agents a memory that survives them. Footprint: 2 GiB RAM, 10 GB disk, 1 service(s). Miget sizing: Hobby 2 GiB plan at $13/mo; Professional 2 GiB at $22/mo. FAQ: Q: Cognee or Mem0 for agent memory? A: Mem0 is the bigger name, but its published self-host images are stale (the current server has no amd64 image - we verified before choosing). Cognee ships current images, runs self-contained, and adds the knowledge-graph layer plain vector memory lacks. When Mem0 publishes proper images, it earns a template too. Q: How do agents use it? A: Over the REST API: add content, trigger cognify, then search with graph-aware retrieval - returning facts and relationships, not just similar chunks. Register a user, mint a token, and any agent in the project calls http://cognee:5000. Q: What do the LLM calls cost? A: Cognify extracts entities and relations via your LLM and embeds via your embedding model - that is the real cost, scaling with ingested volume. Route through the litellm template to cap it with a budgeted virtual key, and consider the tei template for the embedding leg. ## Garage URL: https://deployable.sh/apps/garage/ Category: Object Storage Upstream: Garage (Deuxfleurs), https://garagehq.deuxfleurs.fr Template source: https://github.com/deployable-sh/stacks/tree/main/garage The self-hosted S3 story changed in 2026: MinIO archived its open-source repository in April, its Docker image froze in September 2025 (with an October CVE fix that never shipped), and its console had already been reduced to an object browser. Garage is where the community went - a single static Rust binary from Deuxfleurs, AGPL, releasing steadily, designed for self-hosting from day one. This template ships Garage v2.3 with the community-standard garage-webui in front (cluster status, buckets, keys, object browsing - more than MinIO’s gutted console offered). Configuration is a baked TOML with secrets in env, and the one-time init - layout plus first bucket and key - is four documented commands in the app shell. Same honest scoping as the old minio page: Miget’s native Buckets remain the lower-ops choice for plain storage; Garage is for when you specifically want self-managed S3 with full control. Footprint: 1.4 GiB RAM, 21 GB disk, 3 service(s). Miget sizing: Hobby 2 GiB plan at $13/mo; Professional 4 GiB at $43/mo. FAQ: Q: What exactly happened to MinIO? A: Image publishing stopped September 2025, an October CVE fix never shipped as an image, the repo entered maintenance in December, and the project was archived April 2026 with users pointed at the commercial AIStor. Our minio template remains, pinned to the last image with this history documented - but new deployments should land here. Q: Do my S3 tools work against Garage? A: Yes - endpoint http://garage:3900, region "garage", path-style addressing: boto3, the AWS CLI, rclone, and the catalogue’s filestash and sftpgo all behave normally. Keys and buckets come from the 4-command init or the web UI afterward. Q: Why is there a one-time init step? A: Garage is honestly a clustered system that also runs single-node: the layout step tells it which node owns how much capacity. Four commands in the app shell, once, documented in the README - the price of an architecture that scales to real multi-node later. ## Letta URL: https://deployable.sh/apps/letta/ Category: LLM Infrastructure (experimental) Upstream: Letta (MemGPT), https://www.letta.com Template source: https://github.com/deployable-sh/stacks/tree/main/letta MemGPT introduced the idea that stuck: agents managing their own memory - editing what they know, paging context in and out. Letta is that research grown into an agent server: agents are server-side entities with persistent, self-editing memory, and your apps converse with them over a REST API. This template runs the pinned server image on a pgvector Postgres (required), behind an SSE-friendly proxy with password auth. The hosted ADE (Letta’s agent development environment) connects to your server over HTTPS for visual agent building. The experimental badge is earned honestly: upstream states the Docker image is no longer their primary supported surface (their push is Letta Cloud at $20/month+). It works today, the image is pinned, and the page says exactly this - because finding out from a changelog is worse. Footprint: 2.5 GiB RAM, 10 GB disk, 3 service(s). Miget sizing: Hobby 4 GiB plan at $25/mo; Professional 4 GiB at $43/mo. Managed-service comparison (June 2026): Letta Cloud paid ~$20/mo. FAQ: Q: Letta or Cognee for memory? A: Different layers: Letta IS the agent - server-side entities whose memory management is the product. Cognee is memory infrastructure your existing agents query. If you are building on the MemGPT model, Letta; if you are adding memory to agents you already have, Cognee. Q: Why experimental? A: Upstream openly deprioritizes the self-host Docker surface in favor of Letta Cloud - the image still ships versioned releases, but support energy lives elsewhere. We pin 0.16.8, document it, and let you decide with eyes open. Q: How do I build agents visually? A: Connect the hosted ADE (app.letta.com) to your server: HTTPS domain + your server password. Remote servers must be HTTPS, which the platform ingress provides. One upstream quirk: set the embedding model explicitly when creating agents on Docker deployments. ## Dify URL: https://deployable.sh/apps/dify/ Category: LLM Infrastructure (experimental) Upstream: Dify, https://dify.ai Template source: https://github.com/deployable-sh/stacks/tree/main/dify Dify is the most complete LLM app platform in open source: a visual builder for chatbots, agents, and multi-step workflows, with built-in RAG over your documents, model management across providers, annotations, and usage observability. 120k+ GitHub stars say the demand is real. It is also, honestly, the heaviest template in this catalogue: eleven services mirroring upstream’s compose at the 1.14 line - api/worker/beat, web, the plugin daemon, a code-execution sandbox with its squid egress guard, same-origin nginx routing (which eliminates post-deploy URL variables), plus its own Postgres, noeviction Valkey, and bundled Qdrant. The experimental badge means exactly that: validate on a dev project, bump the version-locked images together. Two honest notes carried from the license and pricing pages: self-hosting is single-tenant by license (one shared Dify for multiple customer tenants needs upstream permission), and Dify Cloud meters message credits ($59/month for 5,000) - which self-hosting does not. Footprint: 6.6 GiB RAM, 27 GB disk, 11 service(s). Miget sizing: Hobby 8 GiB plan at $49/mo; Professional 8 GiB at $85/mo. Managed-service comparison (June 2026): Dify Cloud Professional ~$59/mo. FAQ: Q: Dify, Flowise, or Open WebUI? A: Open WebUI (1 container) for team chat over models. Flowise (2 services) for visual LLM flows and embeddable bots. Dify (11 services) when you want the full platform - workflows, RAG pipelines, plugins, multi-app workspaces - and accept the operational weight. The catalogue ships all three so the choice is honest. Q: What does the license actually restrict? A: Dify’s open-source license is Apache-2.0 plus two conditions: keep the branding, and do not operate one Dify as a multi-tenant service for separate customers without permission. Your org self-hosting its own workspace - the thing this template does - is explicitly fine. Q: How does the cost compare to Dify Cloud? A: Dify Cloud Professional is $59/month per workspace with 5,000 message credits and caps on apps and documents. This stack is $49/month flat with no credit metering - the LLM calls themselves bill at your providers either way (cap them via the litellm template). Q: Why so many services? A: Because Dify genuinely is a platform: async ingestion needs workers, plugins need their daemon, untrusted code needs a sandbox with guarded egress, and RAG needs a vector store. The template wires all of it so one deploy works - but the page count is the honest price of the feature count. ## changedetection.io URL: https://deployable.sh/apps/changedetection/ Category: Monitoring & Analytics Upstream: changedetection.io, https://changedetection.io Template source: https://github.com/deployable-sh/stacks/tree/main/changedetection Price drops, restocks, policy-page edits, competitor changes - the web changes and you want to know first. changedetection.io watches pages on your schedule, shows visual diffs with CSS/xpath filtering, and notifies through 80+ targets, including this catalogue’s ntfy template. Hosted page-watchers meter checks and pages per tier. Self-hosted, watch counts are yours: this single container (which happens to listen on :5000 natively - the catalogue’s easiest deploy) runs hundreds of watches in half a gigabyte. The honest scope note: JS-heavy pages upstream handle with a privileged Chrome sidecar a PaaS cannot run; the built-in fetcher covers most of the web. Footprint: 512 MiB RAM, 2 GB disk, 1 service(s). Miget sizing: Hobby 512 MiB plan at $5/mo; Professional 2 GiB at $22/mo. Managed-service comparison (June 2026): Visualping Personal ~$10/mo; Distill.io Starter ~$15/mo. FAQ: Q: What about JavaScript-heavy pages? A: The built-in fetcher handles most sites. Fully JS-rendered pages need upstream’s Chrome sidecar, which requires privileges a PaaS sandbox does not grant - that single capability is honestly out of scope here, and the page says so rather than letting you find out. Q: How do notifications reach me? A: Apprise under the hood: ntfy (the in-project template pairs perfectly), Slack, Discord, Telegram, SMTP, webhooks - per watch or global. BASE_URL makes the links in those notifications point at your domain. Q: How does this compare to hosted watchers? A: Hosted services tier by pages watched and check frequency. Self-hosted, both are your call - the only meters are your RAM and politeness to the sites you watch. ## ntfy URL: https://deployable.sh/apps/ntfy/ Category: Monitoring & Analytics Upstream: ntfy, https://ntfy.sh Template source: https://github.com/deployable-sh/stacks/tree/main/ntfy The best notification API is the one every tool already speaks: HTTP. ntfy turns a PUT request into a push notification - curl -d "backup done" https://your-domain/alerts - delivered to the iOS/Android apps and browsers subscribed to that topic, with priorities, attachments, and action buttons. This template ships the secure posture by default: deny-all access with declarative bcrypt users in env (no CLI ceremony), so topics on your public domain are private from the first second. Everything in your project becomes a notifier - deploy scripts, uptime-kuma, changedetection, cron jobs. Footprint: 256 MiB RAM, 2 GB disk, 1 service(s). Miget sizing: Hobby 512 MiB plan at $5/mo; Professional 2 GiB at $22/mo. Managed-service comparison (June 2026): ntfy.sh Pro ~$10/mo; Pushover license (usage-based). FAQ: Q: Why self-host instead of using ntfy.sh? A: The public server is great for casual use, but topics are guess-protected, reserved names cost a subscription, and your alert content transits someone else’s box. Self-hosted: deny-all auth, your domain, unlimited topics, $5/month. Q: How do my apps and templates send to it? A: One HTTP request with basic auth or a token: curl -u user:pass -d "message" https://domain/topic. uptime-kuma and changedetection in this catalogue both have ntfy notification targets built in - point them at the in-project hostname. Q: How do phones receive instantly? A: The Android app keeps a connection to your server (or uses its battery-friendly websocket mode); iOS uses a relay for wake-ups with content fetched from your server. Both are in the official app stores. ## Memos URL: https://deployable.sh/apps/memos/ Category: Productivity & PM Upstream: Memos, https://usememos.com Template source: https://github.com/deployable-sh/stacks/tree/main/memos Memos occupies the sweet spot note apps keep abandoning: fast capture of markdown thoughts with tags and search, no folders to file into, no sync subscription, no lock-in. A single MIT-licensed Go binary on SQLite - 40k stars of people who wanted exactly this. One container, one volume, one rule: the first signup becomes the admin, so claim your instance right after deploy. A first-class REST API feeds the community’s mobile clients and your own scripts. Footprint: 256 MiB RAM, 2 GB disk, 1 service(s). Miget sizing: Hobby 512 MiB plan at $5/mo; Professional 2 GiB at $22/mo. FAQ: Q: Memos or a full wiki like Outline? A: Memos is for capture - thoughts, snippets, links, journal lines - not document hierarchies. Teams wanting structured docs want a wiki; individuals wanting a second brain inbox want this. Many run both. Q: Where does my data live and can I leave? A: A SQLite file and assets on the volume - the most portable storage there is. Export via API or copy the database; no proprietary format anywhere. Q: Can multiple people use it? A: Yes - the Host invites users (or leaves registration open on a trusted domain), and memos are private per-user unless shared. For heavy multi-user, the Postgres driver is one env pair away. ## Actual Budget URL: https://deployable.sh/apps/actual/ Category: Productivity & PM Upstream: Actual Budget, https://actualbudget.org Template source: https://github.com/deployable-sh/stacks/tree/main/actual Actual is the YNAB methodology - envelope budgeting where every dollar gets a job - rebuilt as MIT open source with a privacy spine: budgets live ON your devices, end-to-end encrypted, and this little server only syncs ciphertext between them. PikaPods features it on their homepage for a reason. One tiny container, one volume, one first-visit ritual: set the server password before anyone else finds the URL. Bank data comes in via file imports or community bank-sync bridges; your finances stay yours, portably, forever. Footprint: 256 MiB RAM, 2 GB disk, 1 service(s). Miget sizing: Hobby 512 MiB plan at $5/mo; Professional 2 GiB at $22/mo. Managed-service comparison (June 2026): YNAB annual ~$9/mo. FAQ: Q: How does this compare to YNAB? A: Same envelope methodology; YNAB charges ~$110/year and holds your data. Actual is $5/month of server (which can share a plan with everything else here), with budgets end-to-end encrypted - the server operator (you, but it matters on principle) cannot read them. Q: What does end-to-end encryption mean here? A: Budget files encrypt on your device with a key derived from your password; the server syncs blobs it cannot decrypt. Lose the password and even you cannot recover the data - the trade of real E2EE, stated plainly. Q: Can my partner and I share a budget? A: Yes - the same budget file syncs to multiple devices with the shared password. Separate budgets on one server work too; each file has its own encryption. ## Stirling-PDF URL: https://deployable.sh/apps/stirling-pdf/ Category: Productivity & PM Upstream: Stirling-PDF, https://www.stirlingpdf.com Template source: https://github.com/deployable-sh/stacks/tree/main/stirling-pdf Everyone has uploaded a contract to a random "free PDF merge" site and felt vaguely bad about it. Stirling-PDF is that entire genre - 50+ tools: merge, split, compress, OCR, convert, sign, redact, watermark - running on YOUR server, where the documents already live and never leave. One container with login enabled and the initial admin baked from env on first start. 65k GitHub stars of teams who decided document processing belongs in-house. The team-license math against per-seat PDF suites does itself. Footprint: 2 GiB RAM, 1 GB disk, 1 service(s). Miget sizing: Hobby 2 GiB plan at $13/mo; Professional 2 GiB at $22/mo. Managed-service comparison (June 2026): Adobe Acrobat Standard (teams) ~$17/mo; Stirling Processor (hosted) (usage-based). FAQ: Q: Why not just use the free PDF websites? A: Because "free PDF site" means uploading contracts, payslips, and medical records to an unknown party’s server. Stirling-PDF gives the whole team the same tools where the documents already live - for one $7/month plan instead of per-seat PDF-suite licenses. Q: Does OCR work for my language? A: English ships in; additional tesseract language packs mount at /usr/share/tessdata. OCR is the heaviest operation - batch jobs appreciate a bigger heap. Q: What is the license situation? A: MIT core with some proprietary directories upstream (their paid/enterprise features). The 50+ tool set this template ships is the open part - feature gates, if you hit one, are upstream tiers, not template restrictions. ## Node-RED URL: https://deployable.sh/apps/node-red/ Category: Automation & Jobs Upstream: Node-RED (OpenJS), https://nodered.org Template source: https://github.com/deployable-sh/stacks/tree/main/node-red Node-RED is the OpenJS Foundation’s flow programming tool: wire webhooks, APIs, MQTT, schedules, and devices together visually, with thousands of community nodes for everything from Modbus to Telegram. Two decades of IoT and integration muscle live in its palette. This template fixes the deployment footgun upstream leaves open: a public Node-RED editor without auth is arbitrary code execution. The wrapper seeds bcrypt adminAuth into settings.js on first boot and refuses to start without your hash - secure by construction, not by checklist. Footprint: 512 MiB RAM, 2 GB disk, 1 service(s). Miget sizing: Hobby 512 MiB plan at $5/mo; Professional 2 GiB at $22/mo. FAQ: Q: Why does this template enforce auth when upstream does not? A: Because the editor executes arbitrary JavaScript by design - on a public domain, an open editor is remote code execution within minutes of being indexed. The wrapper exits loudly without a bcrypt hash; the inconvenience is the feature. Q: Node-RED or n8n? A: Node-RED for device/MQTT/protocol wiring and the engineering-automation crowd; n8n (in this catalogue, queue mode) for SaaS integrations with credential management and a marketplace of app nodes. Genuinely different ecosystems - pick by what you are wiring. Q: Can flows receive webhooks from the internet? A: Yes - HTTP-in nodes listen on your domain alongside the editor. Secure the endpoints your flows expose (the enforced auth covers the editor, not your custom routes - add header checks in flows). ## Outline URL: https://deployable.sh/apps/outline/ Category: Productivity & PM Upstream: Outline, https://www.getoutline.com Template source: https://github.com/deployable-sh/stacks/tree/main/outline Outline is what teams switch to when Notion’s per-seat bill or Confluence’s UX wears thin: a wiki with a genuinely fast editor, nested collections, full-text search, granular permissions, and an API - polished enough that nobody asks why the company wiki looks self-hosted. This template is the catalogue’s cleanest large-app deploy: ZERO volumes. Documents live in the managed Postgres, uploads in a Miget Bucket (S3 with path-style), and queues in a noeviction Valkey - the app container is disposable. And the auth folklore is outdated: since v1.0, no external provider is required - first-run setup bootstraps your workspace, SMTP magic-links sign the team in, and OIDC via the catalogue’s authentik/keycloak/zitadel is the upgrade path, not the entry fee. Footprint: 2.3 GiB RAM, 5 GB disk, 3 service(s). Miget sizing: Hobby 4 GiB plan at $25/mo; Professional 4 GiB at $43/mo. Managed-service comparison (June 2026): Notion Business ~$200/mo; Confluence Standard ~$67/mo. FAQ: Q: What does this save vs Notion or Confluence? A: Notion Business is $20/seat/month - $200 for a 10-person team; Confluence Standard ~$67. Outline here is $25/month total with no seat concept, and the wiki content sits in a Postgres you can query and back up like any other data. Q: Do I need an SSO provider to use it? A: No - that requirement died with v1.0. First-run setup creates your workspace and admin; SMTP magic-links handle daily sign-in (invite-based). When you want SSO, the OIDC env vars point at the identity templates already in this catalogue. Q: What does the BSL license mean for a company wiki? A: Internal use is unrestricted - BSL only forbids offering Outline itself as a commercial document service. Each release converts to Apache-2.0 after its change date. Flagged because you should know, not because it bites. ## Hasura URL: https://deployable.sh/apps/hasura/ Category: Backend Platforms Upstream: Hasura v2 CE, https://hasura.io Template source: https://github.com/deployable-sh/stacks/tree/main/hasura Hasura’s trick still lands a decade in: point it at Postgres, track your tables, and you have a production GraphQL API - queries, mutations, and live subscriptions - with row-level permissions, remote schemas, and event triggers. No resolvers written, no N+1 hand-wringing. This template ships v2 CE deliberately: it is the Apache-2.0, self-hosted product - one stateless container on the managed Postgres (metadata and default source in one URL). Hasura’s newer DDN/v3 is cloud-first and priced per active model, which makes the v2-self-host math pointed: a 30-table API with traffic costs $150/month there and $13 here. It completes the backend lane: Postgres-native like the supabase template, but as a layer over databases you already have - including, by service name, every Postgres-family stack in your project. Footprint: 2 GiB RAM, 5 GB disk, 2 service(s). Miget sizing: Hobby 2 GiB plan at $13/mo; Professional 2 GiB at $22/mo. Managed-service comparison (June 2026): Hasura DDN Base ~$150/mo. FAQ: Q: Why v2 instead of Hasura DDN (v3)? A: v2 CE is the self-hosted, Apache-2.0 product with years of production mileage; DDN is the cloud-first successor priced at $5 per active model per month - real money for any non-trivial schema. When DDN’s self-host story matures, the calculus gets revisited; today v2 is the honest ship. Q: How do clients authenticate? A: The admin secret is for you; clients use JWTs via HASURA_GRAPHQL_JWT_SECRET - and every IdP in this catalogue (keycloak, authentik, zitadel, logto) issues compatible tokens with role claims for row-level permissions. Q: Can it expose databases other than its own? A: Yes - add sources from the console: other Postgres instances in the project by service name (timescaledb included), each with its own permission rules, unified under one GraphQL endpoint. ## Typesense URL: https://deployable.sh/apps/typesense/ Category: Search & Vectors Upstream: Typesense, https://typesense.org Template source: https://github.com/deployable-sh/stacks/tree/main/typesense Typesense is what you get when search is engineered like a database kernel: a C++ binary holding indexes in RAM, returning typo-tolerant, faceted, filtered results in single-digit milliseconds - plus vector and hybrid search for the semantic layer. Env-only configuration down to the port. It is the deliberate counterpart to the catalogue’s meilisearch: Meilisearch for the gentlest developer experience, Typesense for raw speed and richer filtering at scale. Key-protected like its sibling, so the API can face browsers with scoped search-only keys. The cloud math is unusually direct here: Typesense Cloud’s smallest node - 0.5 GB, no HA, the identical open-source binary - costs $21.60/month. This template’s 1 GiB plan is $7. Footprint: 1 GiB RAM, 5 GB disk, 1 service(s). Miget sizing: Hobby 1 GiB plan at $7/mo; Professional 2 GiB at $22/mo. Managed-service comparison (June 2026): Typesense Cloud smallest cluster ~$22/mo; Algolia Grow (pay-as-you-go) ~$45/mo. FAQ: Q: Typesense or Meilisearch - this catalogue has both? A: Deliberately: Meilisearch wins on out-of-box DX and built-in AI hybrid search; Typesense wins on raw latency, filtering depth, and memory predictability at larger scale. Both are key-protected single containers - benchmarking with your data costs an afternoon and $14. Q: Is the hosted version different software? A: No - Typesense Cloud runs this same GPL binary; you pay for their ops. Their smallest 0.5 GB non-HA node is $21.60/month, which makes the $7 self-hosted plan one of the clearest deltas on this site. Q: Can browsers query it directly? A: Yes - generate scoped, search-only API keys (optionally with embedded filters per user) and ship those to the frontend. The admin key stays server-side; the InstantSearch adapter makes the UI part familiar. ## Infisical URL: https://deployable.sh/apps/infisical/ Category: Security Upstream: Infisical, https://infisical.com Template source: https://github.com/deployable-sh/stacks/tree/main/infisical Secrets sprawl is how incidents start: API keys in CI variables, .envs in Slack, tokens nobody rotated. Infisical is the open-source consolidation point - projects with environments, versioned secrets with point-in-time recovery, references, dynamic secrets, and machine identities for non-human consumers. The pricing landscape makes self-hosting pointed: Infisical Cloud Pro is $18 per identity per month and machines count as identities - a dozen services and runners is real money. HashiCorp’s hosted Vault runs four figures for production. This stack is $25 flat: stateless container, managed Postgres, noeviction Valkey, auto-migrations. And the consumers are already in your project: inject secrets into the CI runner templates, agents, and apps via the CLI, SDKs, or machine-identity auth - with audit and rotation instead of copy-paste. Footprint: 2.8 GiB RAM, 5 GB disk, 3 service(s). Miget sizing: Hobby 4 GiB plan at $25/mo; Professional 4 GiB at $43/mo. Managed-service comparison (June 2026): Infisical Cloud Pro ~$18/mo; HCP Vault Standard (small) ~$1152/mo. FAQ: Q: How does the cost compare to Infisical Cloud or Vault? A: Cloud Pro is $18/identity/month with machines counted - 10 services + 5 humans is $270/month. HCP Vault’s production tier starts around $1,150/month plus per-client fees. This stack is $25 flat with identities uncounted. Q: How do my deployments consume secrets? A: Machine identities + the CLI/SDKs: a service authenticates and pulls its environment at boot or build. The CI runner templates in this catalogue pair naturally - runners fetch fresh secrets per job instead of storing them in forge settings. Q: Infisical or just platform env vars? A: Env vars are fine until you need rotation, versioning, audit, sharing across stacks, or secrets for machines outside the platform. Infisical adds that layer - and writes back to env-var systems via integrations where that remains the delivery mechanism. ## Paperless-ngx URL: https://deployable.sh/apps/paperless-ngx/ Category: Productivity & PM Upstream: Paperless-ngx, https://docs.paperless-ngx.com Template source: https://github.com/deployable-sh/stacks/tree/main/paperless-ngx Paperless-ngx is the project that finally killed the filing cabinet: feed it scans, PDFs, and emails, and it OCRs every page, auto-tags by content, and makes the whole archive instantly full-text searchable. It is one of the most beloved self-hosted apps in existence - the thing people show friends to explain why they self-host at all. This template runs the all-in-one image (web, OCR worker, scheduler, and consumer together under s6) on a managed Postgres with a noeviction Valkey queue. Documents, the search index, and the consume directory share one 20 GB volume - media has no S3 backend upstream, so the volume is the right shape. One admin variable, your OCR language, and a folder you drop files into. Everything else - classification, tagging rules, correspondents - it learns. Footprint: 3.3 GiB RAM, 25 GB disk, 3 service(s). Miget sizing: Hobby 4 GiB plan at $25/mo; Professional 4 GiB at $43/mo. FAQ: Q: What does it actually do to my documents? A: On ingestion: OCRs the pages (so scans become searchable), generates an archival PDF/A, extracts a thumbnail, and classifies it - assigning tags, a correspondent, and a document type based on rules and what it has learned. Then it is searchable forever. Q: How do documents get in? A: Three ways: upload in the web UI, drop files into the consume directory (synced via the catalogue’s filebrowser/sftpgo or a scanner), or pipe email in. The API covers programmatic ingestion. Q: Why one big volume instead of managed storage? A: Paperless keeps originals, the archive copies, and the search index on disk and has no S3 backend for media - so a single RWO volume is the honest design. Back that one volume up and your entire archive is portable. ## NATS Cluster URL: https://deployable.sh/apps/nats/ Category: Streaming & Messaging Upstream: NATS, https://nats.io Template source: https://github.com/deployable-sh/stacks/tree/main/nats NATS is messaging stripped to its fast, essential core: subject-based pub/sub, request/reply, and - via JetStream - persistent streams, work queues, and key-value/object stores. It is astonishingly light (tens of megabytes per node) and astonishingly quick, which is why it underpins so much cloud-native infrastructure. This template runs a 3-node cluster on the stock image, configured entirely with command flags (the same no-custom-build approach as the mongodb replica set). All three nodes share one all-peers routes list - NATS ignores its own self-route - so the mesh forms by gossip with no seed asymmetry, and JetStream replicates across all three. Internal-only by design: it speaks raw TCP on 4222, and apps in the project connect there directly. Footprint: 768 MiB RAM, 15 GB disk, 3 service(s). Miget sizing: Hobby 1 GiB plan at $7/mo; Professional 4 GiB at $43/mo. FAQ: Q: NATS, Kafka, or RabbitMQ? A: NATS for low-latency cloud-native messaging and lightweight persistent streams with the smallest footprint; Kafka/Redpanda for high-throughput, long-retention event logs; RabbitMQ for classic AMQP work queues with mature routing. All are in this catalogue - NATS is the one you reach for when simplicity and latency matter most. Q: Is JetStream production-ready in this setup? A: Yes - three nodes give JetStream a quorum for replication-factor-3 streams, surviving any single node loss. Each node persists to its own volume; declare streams with R3 and writes are durable across the cluster. Q: How do apps connect? A: From the same project: nats://nats-0:4222 (any node accepts connections; list all three for failover). The client port is raw TCP and never exposed publicly. Add --user/--pass flags if you need auth. ## Linkwarden URL: https://deployable.sh/apps/linkwarden/ Category: Productivity & PM Upstream: Linkwarden, https://linkwarden.app Template source: https://github.com/deployable-sh/stacks/tree/main/linkwarden Bookmarks are promises the web keeps breaking - the page moves, changes, or vanishes. Linkwarden fixes that by preserving every save: a screenshot, a PDF, a readable HTML copy, and an archive.org snapshot, alongside collections, tags, and full-text search across all of it. This template runs the app on a managed Postgres behind a thin proxy (its port is fixed at 3000). Page archiving uses an in-container headless Chromium, so give it about a gigabyte - or flip to a lighter bookmarks-only mode. Archived copies live on the volume. The case for owning this got made for us: Pocket shut down in 2025 and deleted everyone’s saved articles; Raindrop keeps your library on their servers. Linkwarden keeps both the links and readable copies on infrastructure you control. Footprint: 2 GiB RAM, 15 GB disk, 3 service(s). Miget sizing: Hobby 2 GiB plan at $13/mo; Professional 4 GiB at $43/mo. Managed-service comparison (June 2026): Raindrop.io Pro (usage-based). FAQ: Q: Why archive pages instead of just saving links? A: Because links die: studies put link rot in the double-digit-percent range within a few years. Linkwarden saves a screenshot, PDF, and readable copy at bookmark time, so a 404 later still leaves you the content you actually wanted. Q: What is the NEXTAUTH_URL gotcha? A: It must include the /api/v1/auth path (e.g. https://links.example.com/api/v1/auth), not just the domain - the most common Linkwarden setup mistake. The README and env example both flag it. Q: Can I make it lighter? A: Yes - set DISABLE_PRESERVATION=true to skip the Chromium archiving and run a bookmarks + tags + search service in well under a gigabyte. You lose the saved copies, keep everything else. ## Penpot URL: https://deployable.sh/apps/penpot/ Category: Business Apps Upstream: Penpot, https://penpot.app Template source: https://github.com/deployable-sh/stacks/tree/main/penpot Penpot is the design tool that does not hold your files hostage: web-based, SVG-native (so the output is real, open standard markup), with prototyping, design systems, and developer handoff - MPL-2.0, no seat ceiling. It became the open-source rallying point when Figma pricing and the Adobe saga rattled design teams. This template runs the full stack: the nginx frontend (fixed :8080, so a thin :5000 proxy fronts it), the JVM backend, and the Chromium exporter, on a managed Postgres with a noeviction Valkey. Crucially, point asset storage at a Miget Bucket (S3) and the shared RWX volume disappears - the backend goes stateless. Figma Professional is $16 per full seat per month; a ten-designer team is $160+ and climbing. Penpot self-hosted is $49/month flat, unlimited designers, files on your infrastructure. Footprint: 4.1 GiB RAM, 15 GB disk, 6 service(s). Miget sizing: Hobby 8 GiB plan at $49/mo; Professional 8 GiB at $85/mo. Managed-service comparison (June 2026): Figma Professional ~$160/mo; Penpot Cloud Unlimited ~$70/mo. FAQ: Q: How does the cost compare to Figma? A: Figma Professional is $16/full-seat/month ($20 monthly), plus Dev seats - a 10-designer team runs $160+/month and grows with headcount. Penpot here is $49/month flat with unlimited designers, and the files are open SVG on your infrastructure. Q: Why the proxy and the S3 recommendation? A: Penpot’s frontend listens on a hardcoded :8080, so a 128 MiB nginx publishes it on the platform’s :5000. And with the filesystem asset backend, frontend and backend share an RWX volume - setting PENPOT_OBJECTS_STORAGE_BACKEND=s3 against a Miget Bucket removes that entirely and makes the backend disposable. Q: Is it really a Figma replacement? A: For UI design, prototyping, design systems, and dev handoff - yes, and the SVG-native model means cleaner export. What you give up is Figma’s plugin ecosystem breadth and some polish; what you gain is open files, unlimited seats, and no vendor leverage over your design org. ## Temporal URL: https://deployable.sh/apps/temporal/ Category: Automation & Jobs (experimental) Upstream: Temporal, https://temporal.io Template source: https://github.com/deployable-sh/stacks/tree/main/temporal Temporal is a different category from the other orchestrators here: durable execution. You write workflows as ordinary code - in Go, Java, Python, TypeScript, .NET - and Temporal guarantees they run to completion despite process crashes, machine restarts, and deploys, replaying from a complete event history with automatic retries and durable timers. This template pairs the server with the web UI on a managed Postgres. It is marked experimental because it uses temporalio/auto-setup (the single-process image upstream now deprecates in favor of the multi-service server) - the simplest possible self-host, with the honest caveat attached rather than hidden. The server speaks raw gRPC on :7233 for your workers (internal, no ingress); the UI is the public entry. Temporal Cloud starts at $100/month plus per-action billing; this is the engine, flat. Footprint: 2.3 GiB RAM, 5 GB disk, 3 service(s). Miget sizing: Hobby 4 GiB plan at $25/mo; Professional 4 GiB at $43/mo. Managed-service comparison (June 2026): Temporal Cloud Essentials ~$100/mo. FAQ: Q: How is Temporal different from Kestra or Prefect? A: Those orchestrate tasks/flows you define declaratively or in scripts; Temporal makes arbitrary application code durable - the workflow IS your program, guaranteed to survive failures and resume exactly where it left off. It is the tool for long-running, must-not-lose-state business processes (payments, provisioning, sagas). Q: Why experimental, and what is the database step? A: It uses the auto-setup image, which upstream deprecated for production in favor of the multi-service server - it works well at small-to-medium scale, and the badge says so. On Miget’s single-role managed Postgres you pre-create two databases (temporal, temporal_visibility) once and set SKIP_DB_CREATE=true; the README has the two SQL lines. Q: How do my workers connect? A: Workers (your code, deployed as separate apps) dial the server over gRPC at temporal:7233 on the private network - no public ingress for the server. The UI is the only public surface. Register namespaces via the UI or the temporal CLI. ## OpenObserve URL: https://deployable.sh/apps/openobserve/ Category: Monitoring & Analytics Upstream: OpenObserve, https://openobserve.ai Template source: https://github.com/deployable-sh/stacks/tree/main/openobserve Log management is where observability bills go to spiral: Datadog charges for ingest AND indexing, Splunk lists in the thousands per GB/day, Logz.io meters by the gigabyte. OpenObserve is the open-source reset - one Rust binary doing logs, metrics, and traces, storing columnar Parquet on object storage at a claimed ~10x lower cost than Elasticsearch. It is the cleanest S3-native fit in the catalogue: point `ZO_LOCAL_MODE_STORAGE=s3` at a Miget Bucket and your telemetry lives there, the container stateless, storage effectively unlimited. OTLP-native ingest means any OpenTelemetry SDK, Vector, or Fluent Bit feeds it directly. This sits alongside the grafana-stack template: Grafana+Loki for the label-based metrics-and-logs story, OpenObserve for search-grade log analytics with object storage and built-in traces - the part Loki’s model does not cover. Footprint: 1 GiB RAM, 10 GB disk, 1 service(s). Miget sizing: Hobby 1 GiB plan at $7/mo; Professional 2 GiB at $22/mo. Managed-service comparison (June 2026): Datadog Logs ingest + index (usage-based); Logz.io usage (usage-based); Splunk ingest (usage-based). FAQ: Q: How does this compare to Datadog or Splunk on cost? A: Datadog Logs bills ingest (~$0.10/GB) and indexing (~$1.70 per million events) separately - you pay twice; Splunk lists in the thousands per GB/day/year. OpenObserve is a flat $13/month plan plus cheap bucket storage, and the columnar-on-S3 design is built to make retention affordable rather than punitive. Q: How do I get logs and traces into it? A: OTLP everywhere: point any OpenTelemetry SDK, Vector, or Fluent Bit at the HTTP endpoint (/api/{org}/v1/logs|metrics|traces) or gRPC on 5081. In-project apps send over the private network; external collectors use a public custom port. Q: OpenObserve or the grafana-stack template? A: grafana-stack (Grafana + Prometheus + Loki) for the classic metrics-and-labels-based-logs setup. OpenObserve for full-text log search at scale, built-in traces, and object-storage economics - and it is one container instead of three. Many teams run both. Q: Why the note about the image? A: OpenObserve’s docs default to their commercial enterprise image; this template uses the AGPL open-source image from ECR Public, which is the genuinely free, self-hostable build. ## Parseable URL: https://deployable.sh/apps/parseable/ Category: Monitoring & Analytics Upstream: Parseable, https://www.parseable.com Template source: https://github.com/deployable-sh/stacks/tree/main/parseable Parseable takes the most disciplined position on log storage: ingest over HTTP, write compressed Parquet straight to object storage, query with SQL. No JVM, no cluster, no local index to outgrow - a single Rust binary that treats S3 (Miget Buckets) as the database. It is the leanest entry in the catalogue’s logging lane: 512 MB, one container, and stateless the moment you set the S3 variables (a thin entrypoint switches it to bucket mode, since Parseable starts via subcommand). For teams who want a focused, cheap log lake rather than a full observability platform, this is it. Ship logs in from Vector, Fluent Bit, OTLP→HTTP, or app SDKs; dashboard and query in the UI. Footprint: 512 MiB RAM, 5 GB disk, 1 service(s). Miget sizing: Hobby 512 MiB plan at $5/mo; Professional 2 GiB at $22/mo. Managed-service comparison (June 2026): Datadog Logs ingest + index (usage-based); Better Stack Logs (retained) (usage-based). FAQ: Q: Parseable or OpenObserve? A: OpenObserve is the broader platform - logs, metrics, and traces with a rich UI. Parseable is the lean, logs-only lake: lighter (512 MB vs 1 GiB) and laser-focused on cheap, SQL-queryable log storage on buckets. Pick OpenObserve for all telemetry, Parseable for the minimal log store. Q: How does it stay so light? A: It does not keep a local search index - it writes columnar Parquet to object storage and queries it directly. Compute is stateless and storage is the bucket, so the container itself stays tiny regardless of how much you retain. Q: How do logs get in? A: A simple HTTP ingest API (POST /api/v1/ingest), plus first-class support from Vector, Fluent Bit, and any OTLP→HTTP pipeline. Structure logs into streams and query each with SQL. ## Mattermost URL: https://deployable.sh/apps/mattermost/ Category: Business Apps Upstream: Mattermost (Team Edition), https://mattermost.com Template source: https://github.com/deployable-sh/stacks/tree/main/mattermost Team chat is the purest per-seat tax: Slack Pro is $8.75/user/month, Teams Essentials $4, and the bill grows with every hire. Mattermost is the open-source escape - channels, threads, DMs, voice/video calls, slash commands, integrations, and a plugin marketplace, with your messages on your infrastructure. This template runs Team Edition on a single plain managed Postgres (no replica set, no Redis) and listens on :5000 directly - no proxy. Config, uploads, plugins, and the search index persist on volumes. It is the catalogue’s default team-chat pick precisely because it is operationally boring: one app, one managed database. (Rocket.Chat is here too, for teams who want its apps marketplace and accept running a MongoDB replica set.) Footprint: 3 GiB RAM, 30 GB disk, 2 service(s). Miget sizing: Hobby 4 GiB plan at $25/mo; Professional 8 GiB at $85/mo. Managed-service comparison (June 2026): Slack Pro ~$219/mo; Microsoft Teams Essentials ~$100/mo. FAQ: Q: How does it compare to Slack or Teams on cost? A: Slack Pro is $8.75/user/month, Teams Essentials $4 - a 25-person team is $100-220/month forever. Mattermost here is $25/month flat with unlimited users, and the conversation history lives in a Postgres you control. Q: Mattermost or Rocket.Chat? A: Both are in this catalogue. Mattermost is the simpler deploy - one plain managed Postgres, no replica set. Rocket.Chat needs a MongoDB replica set (the mongodb template) but brings an apps marketplace and omnichannel. Default to Mattermost unless you specifically want Rocket.Chat’s extras. Q: Can I add SSO? A: Yes - Mattermost supports OIDC/SAML (GitLab-style and enterprise providers); point it at the catalogue’s keycloak, authentik, zitadel, or logto templates. Team Edition covers the common cases; some enterprise auth features live in paid tiers. ## Rocket.Chat URL: https://deployable.sh/apps/rocketchat/ Category: Business Apps Upstream: Rocket.Chat, https://www.rocket.chat Template source: https://github.com/deployable-sh/stacks/tree/main/rocketchat Rocket.Chat is the maximalist open-source team chat: channels, threads, DMs, voice/video, an apps marketplace, and omnichannel (livechat widget, email, social) - the most feature-rich free option, MIT at the core. The app itself is stateless; everything lives in MongoDB. That MongoDB is the one real requirement: Rocket.Chat needs a replica set (it relies on change streams), which this catalogue’s mongodb template provides as three nodes. Deploy that, point MONGO_URL at it, and the Rocket.Chat container is disposable - a clean cross-template showcase. This catalogue ships Mattermost as the simpler default team chat (one plain Postgres); Rocket.Chat is here for teams who want its marketplace and omnichannel and are happy running the replica set alongside. Footprint: 3 GiB RAM, 10 GB disk, 1 service(s). Miget sizing: Hobby 4 GiB plan at $25/mo; Professional 4 GiB at $43/mo. Managed-service comparison (June 2026): Slack Pro ~$219/mo; Rocket.Chat Cloud paid (usage-based). FAQ: Q: Why does it need a MongoDB replica set? A: Rocket.Chat uses MongoDB change streams for realtime updates, which require a replica set - standalone MongoDB is not supported. The catalogue’s mongodb template is a 3-node replica set built for exactly this; point MONGO_URL at it with ?replicaSet=rs0. Q: Rocket.Chat or Mattermost? A: Mattermost is the lower-effort default (one plain managed Postgres, this catalogue’s recommended team chat). Rocket.Chat brings an apps marketplace and omnichannel support, at the cost of running the MongoDB replica set. Pick by whether you want those extras. Q: Is the app really stateless? A: Yes - uploads default to GridFS in MongoDB and all data lives there, so the Rocket.Chat container has no volume. Redeploys and upgrades are clean; back up the mongodb template and you have backed up everything. ## Odoo URL: https://deployable.sh/apps/odoo/ Category: Business Apps Upstream: Odoo Community 18, https://www.odoo.com Template source: https://github.com/deployable-sh/stacks/tree/main/odoo Odoo is the open-source business suite that actually spans the business: CRM, sales, inventory, accounting, manufacturing, projects, HR, a website builder, and ecommerce, all sharing one data model, with a large app store on top. The Community edition (LGPL-3) is genuinely capable on its own. This template runs Odoo 18 on a managed Postgres in threaded mode, which keeps websockets and live chat on a single HTTP port - so the whole thing serves from :5000 with no second longpolling port to route. A thin entrypoint writes Odoo’s config from env (the master password has no env var upstream), keeping the secret out of the image. Odoo Online charges per user per month ($38.90 Standard, $76.20 Custom); Community self-hosted is unlimited users on a flat plan - you trade Enterprise-only modules and official support for that. Footprint: 3 GiB RAM, 17 GB disk, 2 service(s). Miget sizing: Hobby 4 GiB plan at $25/mo; Professional 4 GiB at $43/mo. Managed-service comparison (June 2026): Odoo Online Standard ~$389/mo; Odoo Online Custom ~$762/mo. FAQ: Q: How does this compare to Odoo Online pricing? A: Odoo Online is per-user: Standard $38.90/user/month, Custom $76.20 - a 10-person company is $389-762/month. Community self-hosted here is $25/month flat with unlimited users. You give up Enterprise-only apps (some accounting/studio features) and official support. Q: Why is it pinned to Odoo 18, and why threaded mode? A: The odoo image’s latest tag moved to 19 - pinning 18 prevents a surprise major upgrade. Threaded mode (workers=0) keeps websockets/livechat on the single HTTP port, so it fits the one-public-port model; multiprocessing splits websockets onto port 8072 and needs a two-port-aware proxy. Q: What is the database-manager caveat? A: Odoo’s web DB-manager (create/drop databases) needs a Postgres role with CREATEDB. If the managed role lacks it, pre-create one database and set ODOO_LIST_DB=False - the running app needs no special privileges. ## Bagisto URL: https://deployable.sh/apps/bagisto/ Category: CMS & Publishing Upstream: Bagisto, https://bagisto.com Template source: https://github.com/deployable-sh/stacks/tree/main/bagisto Bagisto is the ecommerce platform for teams that live in Laravel: a full store - catalog, cart, checkout, multi-channel, multi-currency, admin, and a theme/extension system - built on the framework your PHP developers already know. MIT-licensed, so customizing it deeply is just writing Laravel. This template runs the official all-in-one image in external-DB mode (pointing DB_HOST at the separate MySQL container auto-disables the bundled one) behind a thin nginx proxy. APP_KEY is set explicitly so sessions and encrypted data survive redeploys. Like the other stores here, the pitch is zero platform fees: Shopify Basic is $39/month plus per-transaction cuts; Bagisto self-hosted takes nothing per sale. It is MySQL-only (no Postgres), which the bundled MySQL container covers. Footprint: 3 GiB RAM, 15 GB disk, 3 service(s). Miget sizing: Hobby 4 GiB plan at $25/mo; Professional 4 GiB at $43/mo. Managed-service comparison (June 2026): Shopify Basic ~$39/mo; BigCommerce Core ~$39/mo. FAQ: Q: Bagisto, PrestaShop, or Saleor? A: Bagisto if your team builds in Laravel/PHP and wants to extend the store in code. PrestaShop for a turnkey European storefront with a module marketplace. Saleor for headless GraphQL with a custom frontend. All three self-host here with no platform fees. Q: Why set APP_KEY explicitly? A: Laravel uses APP_KEY to encrypt sessions and sensitive data. The image auto-generates one per boot if unset - which would invalidate everything on each redeploy. Set a fixed base64 key (the env example has the one-liner) and state survives. Q: Does it use the image’s bundled MySQL? A: No - the all-in-one image bundles a MySQL, but this template disables it (external-DB mode, DB_HOST off-localhost) and runs a separate MySQL 8 container instead, so the database persists cleanly on its own volume. The app’s storage volume holds media and cache. ## Activepieces URL: https://deployable.sh/apps/activepieces/ Category: Automation & Jobs Upstream: Activepieces, https://www.activepieces.com Template source: https://github.com/deployable-sh/stacks/tree/main/activepieces Activepieces is the MIT-licensed take on Zapier: a clean visual builder with 280+ pieces (app integrations), branching and loops, AI agents, and MCP support - friendly enough for non-engineers, open enough to extend. Strong recent momentum has made it a go-to self-hosted automation tool. This template runs the all-in-one container on a managed Postgres with a noeviction Valkey for its BullMQ queues, listening on :5000 directly. It runs in UNSANDBOXED execution mode, so no Docker socket is needed - exactly right for this platform. Where Zapier charges per task and Make per operation, self-hosted Activepieces meters neither - the only ceiling is the compute it runs on. Footprint: 3.3 GiB RAM, 5 GB disk, 3 service(s). Miget sizing: Hobby 4 GiB plan at $25/mo; Professional 4 GiB at $43/mo. Managed-service comparison (June 2026): Zapier Professional ~$30/mo; Make.com Core ~$9/mo. FAQ: Q: How does it compare to Zapier or Make? A: Zapier Professional is ~$30/month for 750 tasks; Make Core $9 for 10,000 ops - both meter usage. Self-hosted Activepieces has no task or operation meter at all, on a $25/month flat plan, with the flows running on your own infrastructure. Q: Activepieces, n8n, or Node-RED? A: Activepieces for a polished MIT Zapier-style builder with AI pieces and the gentlest UX; n8n (also here, queue mode) for the deepest integration catalog and code-first power; Node-RED for device/MQTT/protocol wiring. Different ecosystems, all flat-priced. Q: Does it need Docker access to run flows? A: No - this template uses UNSANDBOXED execution, so flow steps run in-process without a Docker socket (which a PaaS does not expose). Code pieces still run; the heavier sandbox modes that need container isolation are simply not used here. ## FreeScout URL: https://deployable.sh/apps/freescout/ Category: Business Apps Upstream: FreeScout, https://freescout.net Template source: https://github.com/deployable-sh/stacks/tree/main/freescout FreeScout is the help desk that looks and feels like Help Scout but costs nothing per agent: a shared inbox over email, with conversations, mailboxes, tags, saved replies, assignments, and a module ecosystem for live chat, telephony, and more. AGPL, and genuinely lightweight. This template uses the actively-maintained nfrastack image (the once-popular tiredofit image is now deprecated) on a self-hosted MySQL. The image’s nginx is told to listen on 5000 (NGINX_LISTEN_PORT), so it is the public entrypoint directly - no separate proxy. File-based cache means no Redis; attachments, the app key, and installed modules live on the data volume. Support tooling is per-agent everywhere else - Zendesk $55, Help Scout $25, Freshdesk $19 per agent per month. FreeScout is $13/month flat with unlimited agents; modules are one-time licenses, not subscriptions. Footprint: 2 GiB RAM, 15 GB disk, 2 service(s). Miget sizing: Hobby 2 GiB plan at $13/mo; Professional 4 GiB at $43/mo. Managed-service comparison (June 2026): Zendesk Suite Team ~$275/mo; Help Scout Standard ~$125/mo; Freshdesk Growth ~$95/mo. FAQ: Q: How does the cost compare to Zendesk or Help Scout? A: Zendesk Suite Team is $55/agent/month, Help Scout Standard $25/seat, Freshdesk Growth $19/agent. A 5-agent team is $95-275/month - versus $13/month flat here, agents uncounted. FreeScout’s paid modules are one-time licenses, not recurring seats. Q: Which image does this use? A: The actively-maintained nfrastack/freescout image. The widely-shared tiredofit/freescout image is deprecated as of 2026 (same maintainer moved to the nfrastack namespace) - this template tracks the live one. Q: Do I need Redis? A: No - FreeScout uses file-based cache and sessions on the /data volume, so the template is just app + self-hosted MySQL. That keeps it light and the deploy simple. ## Miniflux URL: https://deployable.sh/apps/miniflux/ Category: Productivity & PM Upstream: Miniflux, https://miniflux.app Template source: https://github.com/deployable-sh/stacks/tree/main/miniflux Miniflux is the RSS reader for people who just want to read: a clean, keyboard-driven, distraction-free UI with no recommendations, no tracking, and no upsell. It is a single statically-linked Go binary, so it boots instantly and idles in about 50 MB. Everything lives in Postgres - feeds, entries, read state, API keys - which makes this template one of the catalogue’s cleanest deploys: the app container is disposable, and the managed Postgres is the only thing holding state. It speaks the Google Reader and Fever APIs, so the mobile clients you already like (Reeder, NetNewsWire, FeedMe) connect straight to your instance. Full-text fetching, feed rules, and integrations (Wallabag, Pocket, webhooks) come built in. Footprint: 1.1 GiB RAM, 5 GB disk, 2 service(s). Miget sizing: Hobby 2 GiB plan at $13/mo; Professional 2 GiB at $22/mo. Managed-service comparison (June 2026): Feedly Pro ~$7/mo; Inoreader Pro ~$8/mo. FAQ: Q: What does this save vs Feedly or Inoreader? A: Feedly Pro is $7/month and Inoreader Pro is roughly $7-9, both capping sources and feeds at higher tiers. Miniflux self-hosted is $7/month flat with no source limit, no ads, and your reading history in a Postgres you control. Q: Can I keep using my phone’s RSS app? A: Yes. Miniflux exposes both the Google Reader and Fever APIs, so clients like Reeder, NetNewsWire, and FeedMe sync against your instance the same way they would against a hosted service. Q: Is it really just one container plus a database? A: Yes. There is no Redis, no worker, no queue - one Go binary and Postgres. Migrations run on start, so deploys and rollbacks are trivial. ## Navidrome URL: https://deployable.sh/apps/navidrome/ Category: Media Upstream: Navidrome, https://www.navidrome.org Template source: https://github.com/deployable-sh/stacks/tree/main/navidrome Navidrome turns a folder of music into a streaming service that is entirely yours: a fast, modern web player plus full Subsonic and OpenSubsonic compatibility, so any of the dozens of Subsonic apps (Symfonium, play:Sub, DSub, Feishin, Amperfy) stream straight from your instance. It is a single Go container with an embedded SQLite database - it idles in about 130 MB and scans your library on a schedule, reading ID3/FLAC tags, cover art, and ReplayGain. No external database, no queue, nothing else to run. Because it reads real audio files and their tags, the library lives on a filesystem volume rather than object storage - point Navidrome at the volume, upload your collection, and resize it to fit. Footprint: 512 MiB RAM, 52 GB disk, 1 service(s). Miget sizing: Hobby 2 GiB plan at $19/mo; Professional 16 GiB at $169/mo. Managed-service comparison (June 2026): Spotify Premium ~$13/mo; Apple Music Individual ~$11/mo; Plex Pass Monthly ~$7/mo. FAQ: Q: How does this compare to Spotify or Apple Music? A: Spotify is $12.99/month and Apple Music $10.99 - perpetual rentals where the catalogue (and your access) can change underneath you. Navidrome is a $13/month plan streaming a library you own outright, with no ads and no algorithm. Q: What about Plex Pass? A: Plex Pass is $6.99/month, and its lifetime option jumps to $749.99 on July 1, 2026. Navidrome is a focused music server with open Subsonic clients and no upsell - you keep the files and the player. Q: Why does my music need a volume instead of a Bucket? A: Navidrome reads audio tags and art directly off the filesystem to build its index, so the library lives on an RWO volume. Only the SQLite database and cache need to persist beyond that, and they ride a small second volume. ## Unleash URL: https://deployable.sh/apps/unleash/ Category: Dev Tools Upstream: Unleash, https://www.getunleash.io Template source: https://github.com/deployable-sh/stacks/tree/main/unleash Unleash is a mature, open-source feature-flag platform: gradual rollouts, per-environment strategies, user targeting and segments, A/B experiments, and an admin UI that non-engineers can actually use. SDKs cover every major language and framework. This template is the server plus a managed Postgres - that is the whole footprint. Flag state and configuration live in Postgres, so the API node stays stateless and the database is the single source of truth you back up. It is the pricing story that makes flags worth self-hosting: hosted flag services meter you on monthly active users or per-connection, which scales with your traffic rather than your team. Here it is a flat plan, and every flag evaluation happens on infrastructure you own. Footprint: 1.5 GiB RAM, 5 GB disk, 2 service(s). Miget sizing: Hobby 2 GiB plan at $13/mo; Professional 2 GiB at $22/mo. Managed-service comparison (June 2026): Statsig Pro ~$150/mo; Flagsmith Start-Up ~$40/mo; LaunchDarkly usage-based (usage-based). FAQ: Q: What does this save vs LaunchDarkly or Flagsmith? A: LaunchDarkly bills usage-based (roughly $10 per connection plus per-MAU charges), Flagsmith’s Start-Up plan is $40/month flat, and Statsig Pro starts around $150. Unleash self-hosted is one flat plan with no MAU or connection metering, no matter how much traffic evaluates your flags. Q: Is the self-hosted version crippled compared to the cloud one? A: The open-source server covers flags, strategies, environments, segments, and the SDKs. Some enterprise governance features are paid, but the core flagging that most teams need is fully open and shipped here. Q: Where are flags evaluated? A: SDKs fetch flag configuration from your Unleash server and evaluate locally in your app, so user data never leaves your infrastructure - a meaningful difference from sending every evaluation context to a third party. ## Docmost URL: https://deployable.sh/apps/docmost/ Category: Productivity & PM Upstream: Docmost, https://docmost.com Template source: https://github.com/deployable-sh/stacks/tree/main/docmost Docmost is open-source team documentation done properly: real-time block editing, nested spaces, granular permissions, inline comments, and diagrams (Draw.io, Excalidraw, Mermaid). It is the rare self-hosted wiki polished enough to replace Confluence or Notion without anyone grumbling. The template runs Docmost on a managed Postgres (with pgvector for search) and a managed Valkey, with attachments on a Miget Bucket. Point storage at the Bucket and the app container is effectively stateless - content is in Postgres, files in object storage. The reason to self-host is the per-seat math: collaborative doc tools charge per person every month, which punishes you for growing the team. Docmost is one flat plan for everyone, with the content sitting in a database you can query and back up. Footprint: 2.3 GiB RAM, 10 GB disk, 3 service(s). Miget sizing: Hobby 4 GiB plan at $25/mo; Professional 4 GiB at $43/mo. Managed-service comparison (June 2026): Notion Business ~$200/mo; Confluence Standard ~$60/mo. FAQ: Q: What does this save vs Confluence or Notion? A: Confluence Standard is about $5.16/user/month and Notion Business is $20/seat - $200/month for a 10-person team. Docmost is one flat plan (roughly $13-25/month) for the whole team, with content in a Postgres you own. Q: Why put attachments on a Bucket instead of a volume? A: With STORAGE_DRIVER=s3 pointed at a Miget Bucket, every uploaded file lives in object storage and the app holds no local state. That keeps redeploys and rollbacks clean and lets storage grow independently of the app. Q: Is the editor actually real-time? A: Yes - Docmost uses a collaborative editor backed by Valkey, so multiple people edit the same page live, with comments and page history. It is closer to Notion’s feel than to a static wiki. ## Docker Registry URL: https://deployable.sh/apps/docker-registry/ Category: Dev Tools Upstream: CNCF Distribution, https://distribution.github.io/distribution/ Template source: https://github.com/deployable-sh/stacks/tree/main/docker-registry This is your own private container registry - the CNCF Distribution registry, the same engine that runs behind Docker Hub - so you can push and pull images over https on your own domain, with basic-auth, and no rate limits. Image layers are stored on a Miget Bucket (S3-compatible), which means the registry service itself holds no state: redeploys and rollbacks keep every image, and storage scales independently. A thin wrapper writes a clean config from environment variables at boot and builds an htpasswd file from your credentials, so the registry is never accidentally left open. It pairs naturally with the catalogue’s CI runners (GitHub, GitLab, Forgejo, Buildkite, Azure Pipelines): build images in a runner, push them here, deploy them anywhere - all inside your own infrastructure, with no Docker Hub pull-rate throttling on your deploys. Footprint: 256 MiB RAM, 10 GB disk, 1 service(s). Miget sizing: Hobby 512 MiB plan at $5/mo; Professional 2 GiB at $22/mo. Managed-service comparison (June 2026): Docker Hub Pro ~$9/mo; GitHub Packages private storage (usage-based). FAQ: Q: What does this save vs Docker Hub or GitHub Packages? A: Docker Hub’s Pro plan is $9/user/month and it meters pull rates; GitHub Packages bills private storage and egress. A self-hosted registry is one small plan (around $5-13/month) plus Bucket storage, with unlimited private repos and no pull throttling. Q: Why does it need a wrapper instead of the stock image? A: Miget configures images through environment variables only, and the stock image ships a filesystem config that conflicts with S3 settings. The wrapper writes a clean config.yml from env (filesystem or S3) and generates the htpasswd file, so the registry comes up correctly and never open by accident. Q: Can my CI push to it? A: Yes. Run `docker login your-app.migetapp.com` with the credentials you set, then push and pull as normal. The catalogue’s CI runners can build and push images to it inside your own network. ## Owncast URL: https://deployable.sh/apps/owncast/ Category: Media Upstream: Owncast, https://owncast.online Template source: https://github.com/deployable-sh/stacks/tree/main/owncast Owncast is a complete live streaming server you run yourself: point OBS (or any RTMP broadcaster) at it, and viewers watch adaptive HLS in a built-in web player on your own domain - with live chat, a custom look, and optional fediverse federation. A thin wrapper pins the web server to port 5000 (Owncast normally takes that from a command-line flag, which Miget’s env-only config does not pass) while RTMP ingest stays on 1935. Expose 1935 as a public custom TCP port and OBS streams straight in. Everything - configuration, chat history, and the recorded HLS segments - lives on a single volume, so it is a one-service deploy. The point is ownership: no platform takes a cut of your audience, no algorithm decides who sees you, and there are no ads. Footprint: 1 GiB RAM, 20 GB disk, 1 service(s). Miget sizing: Hobby 1 GiB plan at $7/mo; Professional 4 GiB at $43/mo. Managed-service comparison (June 2026): Vimeo Advanced ~$75/mo; Restream Standard ~$16/mo. FAQ: Q: What does this save vs Twitch, Vimeo, or Restream? A: Twitch and YouTube monetize your audience and your data, Vimeo’s Advanced tier is around $75/month, and Restream is $16+/month just to multistream. Owncast is one ~$13/month plan for a channel that is entirely yours. Q: How do I get OBS streaming to it? A: Expose port 1935 as a public custom TCP port on Miget, then point OBS at rtmp://your-app.migetapp.com:1935/live using the stream key from the admin panel. Viewers just open your https domain. Q: Why the wrapper? A: Owncast sets its web port with the -webserverport flag, and a compose command does not reach per-app deploys on Miget. The wrapper bakes -webserverport 5000 into the entrypoint so the player is served on Miget’s public port. ## Shlink URL: https://deployable.sh/apps/shlink/ Category: Business Apps Upstream: Shlink, https://shlink.io Template source: https://github.com/deployable-sh/stacks/tree/main/shlink Shlink is a self-hosted URL shortener with the features the paid services gate: short links on your own domain, a full REST API, QR codes, rich visit analytics (with optional GeoIP), tags, and device-based redirect rules. The server handles the redirects and exposes the API on port 5000. A managed Postgres holds every link and visit, so the app is stateless. Shlink ships no UI of its own - you drive it with the REST API, the CLI, or the Shlink Web Client (the official hosted client at app.shlink.io talks to your server from your browser, or self-host the client image). The value is in the metering: hosted shorteners cap links and clicks aggressively and charge to lift the caps. Shlink is one flat plan with unlimited links, your own branded domain, and the analytics sitting in a database you own. Footprint: 1.5 GiB RAM, 5 GB disk, 2 service(s). Miget sizing: Hobby 2 GiB plan at $13/mo; Professional 2 GiB at $22/mo. Managed-service comparison (June 2026): Dub Business ~$75/mo; Bitly Core ~$10/mo; Short.io Hobby ~$5/mo. FAQ: Q: What does this save vs Bitly or Short.io? A: Bitly’s Core plan is $10/month for just 100 branded links a month, and Short.io and Dub meter the same way. Shlink is one ~$13/month plan with unlimited links, your own domain, and the analytics on your own infrastructure. Q: There is no admin UI in the container - how do I manage it? A: Shlink is API-first. Use the REST API, the shlink-cli, or the Shlink Web Client - point the official hosted client at app.shlink.io (it runs in your browser against your server) or self-host the shlinkio/shlink-web-client image. Q: Do I get geographic visit stats? A: Yes, if you set a free MaxMind GeoLite2 license key. Shlink then resolves visits to country and city and exposes the breakdown through the API and web client. ## Plane URL: https://deployable.sh/apps/plane/ Category: Productivity & PM (experimental) Upstream: Plane, https://plane.so Template source: https://github.com/deployable-sh/stacks/tree/main/plane Plane is open-source project management with the modern feel teams expect: issues, cycles (sprints), modules, a roadmap, Gantt and kanban boards, pages, and analytics. It is the self-hosted answer to Jira, Linear, and ClickUp. This template runs the community all-in-one image, which bundles the API, web app, background workers, and real-time collaboration behind a Caddy proxy in one container, bound to port 5000. It needs a few supporting services: managed Postgres and managed Valkey, plus a RabbitMQ sidecar for Celery tasks and an in-stack MinIO for file storage (private, like the catalogue’s Langfuse). It is flagged experimental because it is a heavier, multi-service stack (~4 GB total) with more moving parts than a single-binary app - treat it as a power-user deploy. The payoff is escaping per-seat pricing: Plane is one flat plan for an unlimited team. Footprint: 6.5 GiB RAM, 32 GB disk, 5 service(s). Miget sizing: Hobby 8 GiB plan at $49/mo; Professional 8 GiB at $85/mo. Managed-service comparison (June 2026): Linear Business ~$160/mo; ClickUp Unlimited ~$70/mo; Jira Standard ~$75/mo. FAQ: Q: What does this save vs Jira, Linear, or ClickUp? A: Jira Standard is about $7.53/user/month, Linear runs $8-16/user, and ClickUp Business is $12/user - all per seat. A 10-person team is roughly $75-160/month on those; Plane self-hosted is one flat plan for the whole team, with your data on your own infrastructure. Q: Why is this marked experimental? A: It is a five-service stack (AIO, Postgres, Valkey, RabbitMQ, MinIO) around 4 GB, versus the catalogue’s single-binary apps. Everything is wired and validated, but there are more parts to watch and upgrades occasionally need care - hence the power-user flag. Q: Does it need a proxy wrapper for port 5000? A: No. The community AIO image binds its Caddy proxy with SITE_ADDRESS, which this template sets to :5000 - Miget’s public port - so no extra wrapper is required. ## Immich URL: https://deployable.sh/apps/immich/ Category: Media (experimental) Upstream: Immich, https://immich.app Template source: https://github.com/deployable-sh/stacks/tree/main/immich Immich is the self-hosted photo and video manager that finally feels like Google Photos: first-class iOS and Android apps, automatic phone backup, face recognition, smart and semantic search, albums, shared libraries, and a timeline - all on infrastructure you own. It is a four-service stack: the server (port 5000), a machine-learning worker for face detection and CLIP search, a Postgres built with the VectorChord vector extension (Immich’s own image - this is why it does not use Miget’s managed Postgres), and Valkey for the job queue. Photos live on a filesystem volume, not object storage, because the library layout and thumbnails need a real filesystem. It is flagged experimental for two honest reasons: it is heavy (~6-8 GB, the ML worker alone wants ~3 GB while loading models), and Immich ships fast-moving releases where major versions sometimes need a database migration. Pin upgrades and read the release notes. For a permanent home for your photos, that care is worth it. Footprint: 6.3 GiB RAM, 120 GB disk, 4 service(s). Miget sizing: Hobby 8 GiB plan at $49/mo; Professional 32 GiB at $337/mo. Managed-service comparison (June 2026): Google One 2 TB ~$10/mo; iCloud+ 2 TB ~$10/mo. FAQ: Q: What does this save vs Google One or iCloud+? A: Google One is $9.99/month for 2 TB and iCloud+ is $9.99 for 2 TB - both rent space and mine your library. Immich is one plan plus a volume sized to your photos, with your whole history entirely yours and exportable. Q: Why a special database instead of managed Postgres? A: Immich requires Postgres with a vector extension (VectorChord) for face and semantic search, which is not a standard managed extension. So this template runs Immich’s own database image as a private sidecar with its own volume, rather than the managed Postgres other apps use. Q: Why is it experimental? A: It is a heavy four-service stack and Immich releases move quickly - major versions can need a database migration. Everything is wired and validated, but you should pin versions and read release notes before upgrading, which is why it is not marked stable. ## Writebook URL: https://deployable.sh/apps/writebook/ Category: CMS & Publishing Upstream: Writebook (37signals), https://once.com/writebook Template source: https://github.com/deployable-sh/stacks/tree/main/writebook Writebook is 37signals’ free publishing tool: write and share books, manuals, and documentation with a clean, fast reader on your own domain. It is the same Rails stack that runs Basecamp and HEY, distributed as a single Docker image and given away at no cost. It runs behind Thruster, 37signals’ HTTP/2 proxy, so this template just sets HTTP_PORT to 5000 and DISABLE_SSL=true (Miget terminates TLS) - no wrapper, no sidecar. The content lives in SQLite and uploaded images sit alongside it, so the whole thing is one self-contained container on one volume. Because the software itself is free, there is no per-book or per-seat bill to escape - the only cost is the small plan it runs on. Publishing platforms that host the same thing take a cut or charge per editor; Writebook serves it from infrastructure you own. Footprint: 512 MiB RAM, 5 GB disk, 1 service(s). Miget sizing: Hobby 512 MiB plan at $5/mo; Professional 2 GiB at $22/mo. Managed-service comparison (June 2026): Notion Plus (sites) ~$100/mo; GitBook Premium ~$40/mo. FAQ: Q: Is Writebook really free? A: Yes. 37signals released Writebook at no cost and put the source under the MIT license. There is no purchase, no license server, and no per-book fee - you only pay for the small Miget plan it runs on. Q: How does it get onto port 5000 without a wrapper? A: Writebook serves through Thruster, which reads HTTP_PORT. This template sets HTTP_PORT=5000 so it listens on Miget’s public port, and DISABLE_SSL=true so Rails does not force HTTPS redirects behind Miget’s TLS termination. Q: What should I compare it to? A: GitBook charges per editor for hosted docs and Leanpub takes a royalty on sales; Notion-as-a-site is per seat. Writebook does the same job - polished, readable publishing - as free software on your own domain. ## Fizzy URL: https://deployable.sh/apps/fizzy/ Category: Productivity & PM Upstream: Fizzy (37signals), https://www.fizzy.do Template source: https://github.com/deployable-sh/stacks/tree/main/fizzy Fizzy is 37signals’ free kanban: fast, focused boards for bugs, issues, ideas, and small projects - "kanban as it should be, not as it has been." It is a deliberately simple Trello / Asana alternative from the makers of Basecamp, with auto-closing stale cards, webhooks to Slack or Campfire, public boards, and native mobile apps. Like the rest of the 37signals stack it is a Rails app behind Thruster, backed by SQLite, in one container. This template sets HTTP_PORT to 5000 and DISABLE_SSL=true (Miget terminates TLS), so there is no wrapper or sidecar - the board, its cards, and uploads all live on a single volume. The software is free, so the per-seat math that makes hosted kanban expensive simply disappears: one small plan covers the whole team, and the data sits on infrastructure you own. Footprint: 512 MiB RAM, 3 GB disk, 1 service(s). Miget sizing: Hobby 512 MiB plan at $5/mo; Professional 2 GiB at $22/mo. Managed-service comparison (June 2026): Asana Starter ~$135/mo; Trello Premium ~$125/mo. FAQ: Q: Is Fizzy free? A: Yes - Fizzy is free to self-host. The source is published under 37signals’ O’Saasy license, which lets you run it for your own use freely; it only prevents you from reselling Fizzy itself as a competing hosted service. Q: What does this save vs Trello or Asana? A: Trello Standard is $6/user/month and Premium $12.50, and Asana Starter is $13.49/user - all per seat, so a 10-person team runs $60-135/month. Fizzy is free software on one small Miget plan for the whole team. Q: How does it reach port 5000? A: Fizzy serves through Thruster, which reads HTTP_PORT. The template sets HTTP_PORT=5000 and DISABLE_SSL=true so it listens on Miget’s public port with plain HTTP behind Miget’s TLS termination - no wrapper needed. ## Campfire URL: https://deployable.sh/apps/campfire/ Category: Business Apps Upstream: Campfire (37signals), https://once.com/campfire Template source: https://github.com/deployable-sh/stacks/tree/main/campfire Campfire is 37signals’ free group chat: rooms, direct messages, file sharing, full-text search, @mentions, sounds, and Web Push. It was the first ONCE app - originally a one-time paid product - and is now MIT-licensed and free. It is a single self-contained Rails container: web, background jobs, caching, and file serving all in one, fronted by Thruster and backed by SQLite. This template sets HTTP_PORT to 5000 and DISABLE_SSL=true (Miget terminates TLS), so there is no wrapper - messages and uploads live on one volume. Where Slack meters seats and quietly hides old messages behind paid history, Campfire keeps the entire conversation and all files on infrastructure you own, for the price of one small plan rather than a per-person monthly bill. Footprint: 512 MiB RAM, 10 GB disk, 1 service(s). Miget sizing: Hobby 512 MiB plan at $5/mo; Professional 2 GiB at $22/mo. Managed-service comparison (June 2026): Slack Pro ~$88/mo; Microsoft Teams Essentials ~$40/mo. FAQ: Q: Is Campfire still a paid product? A: No. Campfire launched as a one-time paid ONCE purchase, but 37signals has since open-sourced it under the MIT license. It is now free to self-host - no purchase and no license server. Q: What does this save vs Slack or Teams? A: Slack Pro is $8.75/user/month and meters message history; Microsoft Teams rides a Microsoft 365 subscription. Campfire is free software on one small Miget plan for the whole team, with full history and files kept on your own infrastructure. Q: Does it need a database or Redis container? A: No. Campfire bundles web, background jobs, caching, and file serving into one container on SQLite - a genuinely single-service deploy. Everything persists on the storage volume. ## Buzz URL: https://deployable.sh/apps/buzz/ Category: Productivity & PM (experimental) Upstream: Buzz (Block), https://github.com/block/buzz Template source: https://github.com/deployable-sh/stacks/tree/main/buzz Buzz is Block’s answer to a question most chat tools dodge: what if an agent were a member of the room rather than a webhook pointed at it? Agents get their own keys, their own channel memberships, and their own audit trail - scoped by identity, the way you would scope a teammate, not by a permissions checkbox. Underneath it is a Nostr relay. Messages, reactions, git patches, CI results, workflow steps, and review approvals are all signed events in one log, so "search the conversation, the patch, and the approval" is one query rather than three integrations. The relay also hosts git over NIP-34, which is what lets a feature branch become a room. The relay is the server, not the client: you use it from the Buzz desktop app or buzz-cli pointed at your domain, while a browser visiting the relay gets the invite page. Self-hosting is the whole point - the workspace, the event log, and the repositories sit on infrastructure you control. Footprint: 2.8 GiB RAM, 20 GB disk, 4 service(s). Miget sizing: Hobby 4 GiB plan at $25/mo; Professional 4 GiB at $43/mo. Managed-service comparison (June 2026): Slack Business+ ~$150/mo; Mattermost Professional (cloud) ~$100/mo; Zulip Cloud Standard ~$80/mo. FAQ: Q: Is this a Slack alternative? A: For a team that wants agents in the room, yes - channels, threads, DMs, and search are all there. Two caveats: the client is the desktop app (mobile is still being wired up), and the browser surface is the invite page rather than a full web client. If you want a browser-first Slack clone today, the catalogue’s campfire template is the closer fit. Q: Who can join my relay? A: By default anyone who has the URL and authenticates - publishing always requires NIP-42 auth, but membership is not enforced until you turn it on. You cannot set an owner before deploying (the owner is a key you only have once you have an identity), so the README makes locking down step two: set RELAY_OWNER_PUBKEY, enable membership enforcement, and invite people with a code. Q: How do agents connect? A: Through the buzz-acp harness, which bridges relay events to an ACP agent - Goose, Codex, or Claude Code. It runs wherever the agent binary and its LLM credentials live, so it is a separate deploy from the relay rather than a service in this stack; the catalogue’s agent-box is one place to put it. ## Cal.com URL: https://deployable.sh/apps/calcom/ Category: Scheduling Upstream: Cal.com, https://cal.com Template source: https://github.com/deployable-sh/stacks/tree/main/calcom Cal.com is open-source scheduling done properly: personal and team booking pages, fine-grained availability, round-robin and collective events, reminders and workflows, routing forms, and two-way sync with Google, Office 365, and CalDAV calendars. It is the self-hosted answer to Calendly. The app is effectively stateless - every booking, event type, and connection lives in a managed Postgres - so this template is just the app plus the database. PORT moves it onto Miget’s public port with no wrapper, and migrations run on start. The reason to self-host is the same as always: scheduling tools meter features per seat, which scales with your team rather than your usage. Cal.com is one flat plan, on your own domain, with the booking data in a Postgres you control. Footprint: 3 GiB RAM, 10 GB disk, 2 service(s). Miget sizing: Hobby 4 GiB plan at $25/mo; Professional 4 GiB at $43/mo. Managed-service comparison (June 2026): Calendly Teams ~$160/mo; Calendly Standard ~$120/mo. FAQ: Q: What does this save vs Calendly? A: Calendly is $12-16/user/month and gates features per seat, so a team multiplies fast. Cal.com self-hosted is one flat plan for everyone, with your booking data on your own infrastructure. Q: Why does the database need the citext extension? A: Cal.com's Prisma migrations create a case-insensitive text type (citext) on start, so the managed Postgres is provisioned with that extension enabled. It is a standard contrib extension - the template wires it for you. Q: Is the self-hosted version limited? A: The core scheduling app is AGPLv3 and fully functional self-hosted. Some enterprise features under the /ee directory need a paid license key, but booking pages, teams, availability, and calendar sync do not. ## Jellyfin URL: https://deployable.sh/apps/jellyfin/ Category: Media Upstream: Jellyfin, https://jellyfin.org Template source: https://github.com/deployable-sh/stacks/tree/main/jellyfin Jellyfin is the free, self-hosted media server: stream your movies, TV shows, music, and photos to a web player and native apps on practically every device, with no subscription, no account upsell, and no telemetry. It is the community alternative to Plex and Emby. It is a single self-contained container with an embedded SQLite database, so there is nothing else to run. Jellyfin only sets its HTTP port through network.xml, so this template uses a thin wrapper that seeds port 5000 on first boot (and never touches it again, so changes you make in the UI stick). The honest caveat is transcoding: a PaaS does not pass through a GPU, so transcoding is CPU-only. Direct-play - when the client can play the source file as-is - uses almost no CPU and is the happy path; heavy on-the-fly transcoding costs roughly a core per stream, so size the plan or prefer compatible clients. Footprint: 2 GiB RAM, 115 GB disk, 1 service(s). Miget sizing: Hobby 8 GiB plan at $49/mo; Professional 32 GiB at $337/mo. Managed-service comparison (June 2026): Netflix Standard ~$15/mo; Plex Pass Monthly ~$7/mo. FAQ: Q: What does this save vs Plex or streaming services? A: Plex keeps moving features behind Plex Pass ($6.99/month, lifetime jumping to $749.99 on Jul 1 2026), and Netflix-style services rent you a rotating catalogue. Jellyfin is one plan streaming a library that is entirely yours, with every feature included. Q: Can it transcode without a GPU? A: Yes, in software, but a 1080p transcode uses roughly a full CPU core. Direct-play (a client that supports the source format) avoids transcoding entirely and is the recommended path on a PaaS, where GPU passthrough is not available. Q: Why does it need a wrapper for port 5000? A: Jellyfin reads its listen port from network.xml, not an env var or flag. The thin wrapper seeds network.xml with port 5000 on first boot only, so it lands on Miget’s public port without clobbering any port change you make later in the UI. ## Plausible URL: https://deployable.sh/apps/plausible/ Category: Monitoring & Analytics Upstream: Plausible Community Edition, https://plausible.io Template source: https://github.com/deployable-sh/stacks/tree/main/plausible Plausible is privacy-friendly web analytics: a clean, single-page dashboard that tells you what you need to know without cookies, without collecting personal data, and without a consent banner. The tracking script is roughly 75x smaller than Google Analytics. This is the self-hosted Community Edition. It is a real analytics stack: the app and a managed Postgres for accounts and settings, plus a ClickHouse sidecar that stores the event data. Miget has no managed ClickHouse, so it runs as a private sidecar - a thin wrapper bakes the four tuning configs from Plausible’s official setup (ClickHouse otherwise assumes a 16 GB box) and another bakes the database migration step Plausible does not run on its own. You already have lighter analytics in this catalogue with umami; Plausible adds funnels, goals, custom events, and a more polished dashboard for when a project needs them - all with the visitor data sitting on infrastructure you own. Footprint: 4 GiB RAM, 25 GB disk, 3 service(s). Miget sizing: Hobby 4 GiB plan at $25/mo; Professional 4 GiB at $43/mo. Managed-service comparison (June 2026): Fathom Starter ~$15/mo; Plausible Cloud Growth ~$9/mo. FAQ: Q: How is this different from the umami template? A: Both are privacy-friendly analytics. Umami is lighter (a single app on Postgres); Plausible adds funnels, goals, and a more polished dashboard at the cost of a ClickHouse sidecar. Pick umami for minimal, Plausible for more depth. Q: Why does it need ClickHouse? A: Plausible stores pageview events in ClickHouse, a columnar database built for fast analytics queries. Miget has no managed ClickHouse, so this template runs it as a private sidecar with a durable volume and the official low-resource tuning baked in. Q: What does it cost compared to Plausible Cloud? A: Plausible Cloud starts at $9/month metered by pageviews. Self-hosted is one flat plan regardless of traffic, with the visitor data on your own infrastructure - the trade is that you run the ClickHouse sidecar yourself. ## BookStack URL: https://deployable.sh/apps/bookstack/ Category: Productivity & PM Upstream: BookStack, https://www.bookstackapp.com Template source: https://github.com/deployable-sh/stacks/tree/main/bookstack BookStack is a wiki people actually enjoy using: content is organized into shelves, books, chapters, and pages, with a friendly WYSIWYG editor (markdown too), full-text search, draw.io diagrams, page revisions, roles and permissions, and an API. It is the calm, approachable alternative to Confluence. It is a Laravel app backed by a self-hosted MariaDB. The LinuxServer image listens on port 80 with no env var to change it, so this template uses a thin wrapper that patches the nginx config to serve port 5000. Uploads and config sit on one volume, or move them to a Miget Bucket to keep the app near-stateless. The case for self-hosting is the usual per-seat story: documentation tools bill per person every month. BookStack is one flat plan for the whole team, with the content in a MySQL database you own and can back up like any other. Footprint: 2 GiB RAM, 10 GB disk, 2 service(s). Miget sizing: Hobby 2 GiB plan at $13/mo; Professional 2 GiB at $22/mo. Managed-service comparison (June 2026): Notion Business ~$200/mo; Confluence Standard ~$60/mo. FAQ: Q: What does this save vs Confluence? A: Confluence Standard is about $5-6/user/month, so a 10-person team runs ~$50-60/month and climbs with headcount. BookStack is one flat plan for everyone, with the content in a MySQL you control. Q: Can uploads go to object storage? A: Yes. Set STORAGE_TYPE=s3 plus the STORAGE_S3_* variables to keep images and attachments in a Miget Bucket. That leaves only the MySQL database as state and makes redeploys clean. Q: Why the wrapper, and what about the default admin? A: The image’s nginx listens on port 80 with no env var, so a thin wrapper patches it to port 5000. On first login change the default admin (admin@admin.com / password) immediately. ## AudioBookshelf URL: https://deployable.sh/apps/audiobookshelf/ Category: Media Upstream: AudioBookshelf, https://www.audiobookshelf.org Template source: https://github.com/deployable-sh/stacks/tree/main/audiobookshelf AudioBookshelf is a self-hosted server for audiobooks and podcasts: a clean web player, native iOS and Android apps with offline downloads and progress sync, multi-user libraries, bookmarks, sleep timers, and built-in podcast search and auto-download. A single container with an embedded SQLite database. PORT moves it straight onto Miget’s public port - no wrapper, no external database, nothing else to run. Point it at your audio on the library volumes and it scans, organizes, and serves them. It is the antidote to renting your listening: Audible licenses you access that can be revoked, and podcast apps upsell subscriptions. AudioBookshelf serves a library you own, to every device, for the price of one small plan. Footprint: 512 MiB RAM, 77 GB disk, 1 service(s). Miget sizing: Hobby 4 GiB plan at $25/mo; Professional 16 GiB at $169/mo. Managed-service comparison (June 2026): Audible Premium Plus ~$15/mo. FAQ: Q: What does this save vs Audible? A: Audible is about $14.95/month for one credit, and you only license listening rights that can change. AudioBookshelf is one ~$13/month plan serving a library you own outright, across every device. Q: Does it handle podcasts too? A: Yes - search for and subscribe to podcasts, auto-download new episodes, and track progress alongside your audiobooks. It is a single server for both, with one app on your phone. Q: Is it really just one container? A: Yes. AudioBookshelf embeds SQLite and bundles ffmpeg, so there is no external database or worker. Set PORT=5000 and point it at your audio volumes - that is the whole deploy. ## Karakeep URL: https://deployable.sh/apps/karakeep/ Category: Productivity & PM Upstream: Karakeep (formerly Hoarder), https://karakeep.app Template source: https://github.com/deployable-sh/stacks/tree/main/karakeep Karakeep (the app formerly known as Hoarder) is a "bookmark everything" hub: save links, notes, and images, and it automatically crawls and archives the page so your links never rot, takes a screenshot, full-text indexes everything for instant search, and can auto-tag with AI. Native mobile apps and a browser extension are included. It is a three-service stack: the app and its built-in workers (port 5000, on embedded SQLite), a Meilisearch instance for search, and a headless Chrome for crawling and screenshots. On Miget the search and browser run as private sidecars; the app is the only public service. The AI tagging is the modern twist, and it stays on your terms: point it at this catalogue’s ollama or litellm to keep inference on your own infrastructure, or plug in an OpenAI key. Leave it off and everything else still works. Footprint: 2 GiB RAM, 15 GB disk, 3 service(s). Miget sizing: Hobby 2 GiB plan at $13/mo; Professional 4 GiB at $43/mo. Managed-service comparison (June 2026): Raindrop.io Pro ~$3/mo. FAQ: Q: What does this replace? A: Pocket (shut down in 2025) and Raindrop.io Pro ($3/month) for read-it-later and bookmarking. Karakeep adds full-page archiving, real search, and optional AI tagging, with everything on infrastructure you own. Q: Do I need an OpenAI key? A: No. AI auto-tagging is optional - without it, the app works fully for saving, archiving, and search. When you want it, point OLLAMA_BASE_URL at this catalogue’s ollama or litellm to keep inference local, or set an OpenAI key. Q: Why three services? A: The app and its workers run together on SQLite; Meilisearch powers instant full-text search; and a headless Chrome renders pages for archiving and screenshots. Miget has no managed substitute for those two, so they run as private sidecars. ## Beszel URL: https://deployable.sh/apps/beszel/ Category: Monitoring & Analytics Upstream: Beszel, https://beszel.dev Template source: https://github.com/deployable-sh/stacks/tree/main/beszel Beszel is a refreshingly small server monitoring tool: CPU, memory, disk, network, temperatures, and per-container Docker stats, with history and configurable alerts (email, webhooks, ntfy, and more). The hub is a single Go binary embedding PocketBase, so it idles in well under 256 MB. This template deploys the hub - the dashboard and database. The actual metrics come from lightweight agents you install on the machines you want to watch (your own VPS, bare-metal, or home server). An agent inside a Miget container would only see its own sandbox, so agents are not deployed here; install them where your workloads run and point them at this hub. A thin wrapper sets the hub’s listen port to 5000 (its only port control is a command-line flag). Everything else is one volume and the embedded database - about as light as a monitoring stack gets. Footprint: 256 MiB RAM, 2 GB disk, 1 service(s). Miget sizing: Hobby 512 MiB plan at $5/mo; Professional 2 GiB at $22/mo. Managed-service comparison (June 2026): Datadog Pro ~$150/mo. FAQ: Q: Why is only the hub deployed, not the agent? A: The agent monitors a real host (CPU, disk, Docker socket). Inside a Miget container it would only see its own sandbox, which is useless. So you deploy the hub here and install agents on the actual machines you want to watch - they dial back to this hub. Q: What does this save vs Datadog? A: Datadog and similar bill per host per month and meter retention. Beszel is one tiny ~$5/month plan watching as many of your machines as you like, with the data on your own infrastructure. Q: How do I add a machine? A: In the hub UI, add a system to get its install command, then run that agent on the target machine. It connects back to the hub over the network (SSH-key or token auth), and the dashboard starts showing its metrics. ## Dawarich URL: https://deployable.sh/apps/dawarich/ Category: Productivity & PM (experimental) Upstream: Dawarich, https://dawarich.app Template source: https://github.com/deployable-sh/stacks/tree/main/dawarich Dawarich is a privacy-first replacement for Google Maps Timeline: import your location history from Google Takeout, OwnTracks, Overland, or GPX, and explore your trips, the places and cities and countries you have visited, and your travel stats on your own interactive map. None of it goes to Google. It is a four-service stack: the web app (port 5000), a Sidekiq worker for imports and reverse geocoding, a PostgreSQL database with the PostGIS extension, and Valkey. Because PostGIS is not a standard managed extension, the database runs as a private sidecar on the expected image (the same approach the immich template takes); Valkey is managed. It is flagged experimental because it is genuinely heavier than a single-container app - four services, a hard PostGIS dependency, and a worker that shares storage with the web app. Everything is wired and validated; just give it room and read the first-login notes. Footprint: 3.5 GiB RAM, 32 GB disk, 4 service(s). Miget sizing: Hobby 4 GiB plan at $25/mo; Professional 8 GiB at $85/mo. Managed-service comparison (June 2026): Google Maps Timeline free (usage-based). FAQ: Q: What does this replace? A: Google Maps Timeline, which mines your every move. Dawarich keeps your entire location history on infrastructure you own, imported from the same Google Takeout export plus OwnTracks, Overland, and GPX. Q: Why a PostGIS sidecar instead of managed Postgres? A: Dawarich needs the PostGIS spatial extension, which is not a standard managed-database feature. So the template runs Postgres with PostGIS as a private sidecar on its own volume, the same pattern the immich template uses for its specialized database. Q: Why is it marked experimental? A: It is a four-service stack (web, worker, PostGIS, Valkey) around 4 GB, heavier than the catalogue’s single-container apps, and Dawarich moves quickly. Everything is wired and validated, but set APPLICATION_HOSTS correctly and read the first-login notes before relying on it. ## SearXNG URL: https://deployable.sh/apps/searxng/ Category: Search & Vectors Upstream: SearXNG, https://docs.searxng.org Template source: https://github.com/deployable-sh/stacks/tree/main/searxng SearXNG is a privacy-respecting metasearch engine: it queries 200+ search engines and blends the results, with no tracking, no profiling, and no ads. Use it as your own search homepage that never builds a profile on you, on your own domain. It is also the standard web-search backend for AI: point this catalogue’s open-webui, litellm, dify, or flowise at it to give models live web results, keeping the queries on your own infrastructure instead of a third-party search API. The image self-serves HTTP on port 5000 via SEARXNG_PORT - no separate proxy needed. Set a secret so sessions survive restarts; for a public, rate-limited instance, add a managed Valkey. Otherwise it is a single light container. Footprint: 512 MiB RAM, 3 GB disk, 1 service(s). Miget sizing: Hobby 512 MiB plan at $5/mo; Professional 2 GiB at $22/mo. Managed-service comparison (June 2026): Kagi Professional ~$10/mo. FAQ: Q: Can AI tools use it for web search? A: Yes - that is one of its best uses. open-webui, litellm, dify, and flowise all support SearXNG as a web-search tool, so your models get live results while the search queries stay on your own infrastructure. Q: Do I need Redis or a separate proxy? A: No. The image self-serves HTTP on port 5000 (via SEARXNG_PORT) with no extra proxy. A managed Valkey is optional - only needed for the rate-limiter on a public instance. Q: Why set SEARXNG_SECRET explicitly? A: If you do not set it, SearXNG generates a new secret on each restart, which resets sessions. Setting it (a long random string) keeps the instance stable across redeploys on Miget. ## Ollama URL: https://deployable.sh/apps/ollama/ Category: LLM Infrastructure (experimental) Upstream: Ollama, https://ollama.com Template source: https://github.com/deployable-sh/stacks/tree/main/ollama Ollama is the simplest way to run open large language models behind an HTTP API: pull a model (Llama, Mistral, Qwen, Gemma, Phi, and many more) and serve it with OpenAI-compatible endpoints, on infrastructure you own. OLLAMA_HOST puts the API on port 5000; there are no external dependencies. Read the caveat first, because it is the whole story: real inference wants a GPU. A PaaS typically does not pass one through, so on CPU you are limited to small models (~1-3B parameters) and responses are slow. Ollama still runs, and small models are genuinely useful for embeddings, classification, and lightweight chat - just size expectations to CPU. This template is marked experimental for exactly that reason. It is best used as a building block: keep it private and front it with this catalogue’s litellm for keys, rate limits, and an OpenAI-compatible gateway, or add open-webui for a chat UI. Models are large, so the model volume is the thing to size. Footprint: 4 GiB RAM, 50 GB disk, 1 service(s). Miget sizing: Hobby 4 GiB plan at $25/mo; Professional 8 GiB at $85/mo. Managed-service comparison (June 2026): OpenAI API usage-based (usage-based). FAQ: Q: Is it usable without a GPU? A: For small models, yes - 1-3B models run on CPU and are useful for embeddings, classification, and light chat, just slowly. For 7B+ at interactive speed you really want a GPU, which a PaaS generally cannot provide. That is why this template is experimental. Q: Should I expose it publicly? A: No. Ollama has no authentication, so this template keeps it private. Reach it from your other apps over the internal network, or front it with litellm (in this catalogue) to add API keys, rate limits, and an OpenAI-compatible gateway. Q: How big is the model storage? A: Models are large and live on a volume: roughly 2 GB for a 3B model, 5 GB for 7-8B, and 40 GB for 70B. Size the volume to what you pull, or models re-download after a restart. ## Redis URL: https://deployable.sh/apps/redis/ Category: Caches & Key-Value Upstream: Redis, https://redis.io Template source: https://github.com/deployable-sh/stacks/tree/main/redis Redis is the in-memory data store that powers caching, job queues, pub/sub, rate-limiting, sessions, leaderboards, and streams across a huge share of modern apps. This template is a single node, password-protected, with append-only persistence on a volume. It runs internal-only on Miget: other services in the same project connect at redis:6379 over the private network. A thin wrapper reads the password from the environment at start, so the secret is never baked into the image. Miget also offers managed Valkey (a Redis-compatible drop-in) as an addon - reach for that when you just want a cache wired to an app. Run this when you want to own and tune Redis yourself, or step up to the sentinel (failover) and cluster (sharding) templates. Footprint: 512 MiB RAM, 5 GB disk, 1 service(s). Miget sizing: Hobby 512 MiB plan at $5/mo; Professional 2 GiB at $22/mo. Managed-service comparison (June 2026): AWS ElastiCache cache.t4g.micro ~$12/mo; Redis Cloud Fixed ~$5/mo. FAQ: Q: Should I use this or managed Valkey? A: For most apps, managed Valkey (a Redis-compatible addon) is less to operate. Use this Redis template when you specifically want Redis, full control of its configuration, or the Sentinel / Cluster topologies the managed addon does not expose. Q: What does this save vs ElastiCache? A: AWS ElastiCache starts around $12+/node/month for the smallest instance and multiplies for HA, plus data transfer. This is one flat plan on your own infrastructure, with no per-node metering. Q: Is my data safe across restarts? A: Append-only persistence is enabled and written to the volume, so data survives restarts. For real high availability (automatic failover), use the redis-sentinel template; a single node still has a single point of failure. ## Valkey URL: https://deployable.sh/apps/valkey/ Category: Caches & Key-Value Upstream: Valkey, https://valkey.io Template source: https://github.com/deployable-sh/stacks/tree/main/valkey Valkey is the BSD-licensed, Redis-compatible in-memory data store, forked and stewarded by the Linux Foundation after Redis changed its license. It is a drop-in for Redis clients and protocols: caching, queues, pub/sub, streams, and data structures all work unchanged. This template is a single node, password-protected, with append-only persistence on a volume, running internal-only on Miget (apps connect at valkey:6379). A thin wrapper reads the password from the environment at start. Miget offers managed Valkey as an addon for hands-off use. Run this template when you want to operate Valkey yourself, pin a version, or move up to the sentinel (failover) and cluster (sharding) topologies. Footprint: 512 MiB RAM, 5 GB disk, 1 service(s). Miget sizing: Hobby 512 MiB plan at $5/mo; Professional 2 GiB at $22/mo. Managed-service comparison (June 2026): AWS ElastiCache Valkey, cache.t4g.micro ~$12/mo; Aiven Caching Startup ~$31/mo. FAQ: Q: How is Valkey different from Redis? A: Valkey is the community fork created after Redis moved to a more restrictive license. It stays under the permissive BSD-3-Clause license and remains protocol-compatible, so existing Redis clients, libraries, and tooling work without changes. Q: Why run this if Miget has managed Valkey? A: The managed addon is simpler for wiring a cache to an app. This template is for running Valkey yourself with full control, or for the Sentinel and Cluster topologies, which the managed addon does not provide. Q: Can I point Redis clients at it? A: Yes. Valkey speaks the Redis protocol, so any Redis client or library connects to valkey:6379 the same way it would to Redis. ## Redis Sentinel URL: https://deployable.sh/apps/redis-sentinel/ Category: Caches & Key-Value Upstream: Redis, https://redis.io/docs/latest/operate/oss_and_stack/management/sentinel/ Template source: https://github.com/deployable-sh/stacks/tree/main/redis-sentinel Redis Sentinel adds high availability to Redis: if the master goes down, the sentinels detect it, elect a new master from the replicas, and reconfigure the topology automatically. This template runs one master, two replicas, and three sentinels (quorum 2) - the standard HA layout. One image plays all three roles, selected by an environment variable; the entrypoint builds each node`s command and the sentinel config from env. Sentinels are configured to resolve hostnames (service DNS) rather than raw IPs, which is what makes failover report a usable address on a multi-pod network. Verified locally: the master sees both replicas and all three sentinels agree. Clients connect through Sentinel, not the master directly - a Sentinel-aware client (ioredis, redis-py, Lettuce, go-redis) asks a sentinel for the current master and is rerouted automatically on failover. Footprint: 1.9 GiB RAM, 15 GB disk, 6 service(s). Miget sizing: Hobby 2 GiB plan at $13/mo; Professional 4 GiB at $43/mo. Managed-service comparison (June 2026): AWS ElastiCache Multi-AZ (2 nodes) ~$24/mo; Redis Cloud HA (multi-AZ) ~$28/mo. FAQ: Q: When should I use Sentinel vs Cluster? A: Sentinel gives you high availability (automatic failover) for a single dataset that fits on one node. Use redis-cluster instead when the data or throughput exceeds one node and you need sharding across multiple masters. Q: How do clients connect? A: Through Sentinel, not the master directly. Point a Sentinel-aware client at redis-sentinel-1:26379, redis-sentinel-2:26379, redis-sentinel-3:26379 with master name "mymaster"; the client discovers the current master and follows failovers. Q: Does failover actually work on a PaaS? A: Yes - the sentinels resolve service hostnames instead of pod IPs, so after a promotion they report a DNS name clients can reach. This template was smoke-tested locally: master with two connected replicas and three mutually-aware sentinels. ## Valkey Sentinel URL: https://deployable.sh/apps/valkey-sentinel/ Category: Caches & Key-Value Upstream: Valkey, https://valkey.io Template source: https://github.com/deployable-sh/stacks/tree/main/valkey-sentinel Valkey Sentinel brings high availability to Valkey using the same battle-tested design as Redis Sentinel: sentinels watch the master and promote a replica automatically if it fails. This template runs one master, two replicas, and three sentinels (quorum 2). BSD-licensed and Redis-protocol compatible. One image plays all three roles, selected by an environment variable; the entrypoint generates each command and the sentinel config from env, with hostname resolution so failover reports a DNS-resolvable address on a multi-pod network. Clients connect through Sentinel - existing Redis Sentinel client libraries work unchanged, asking a sentinel for the current master and following failovers transparently. Footprint: 1.9 GiB RAM, 15 GB disk, 6 service(s). Miget sizing: Hobby 2 GiB plan at $13/mo; Professional 4 GiB at $43/mo. Managed-service comparison (June 2026): AWS ElastiCache Multi-AZ (2 nodes) ~$24/mo; Aiven Caching Business ~$80/mo. FAQ: Q: Sentinel or Cluster? A: Sentinel gives failover HA for a dataset that fits on one node. valkey-cluster shards across multiple masters when one node is not enough. Many teams only need Sentinel. Q: Is it compatible with Redis Sentinel clients? A: Yes. Valkey implements the same Sentinel protocol, so libraries written for Redis Sentinel connect to the valkey-sentinel-* nodes with master name "mymaster" unchanged. Q: What does this save vs managed HA caches? A: Managed HA Redis/Valkey (ElastiCache Multi-AZ, Redis Cloud, Aiven) bills per node per month plus transfer. This is one flat plan on your own infrastructure for the whole topology. ## Redis Cluster URL: https://deployable.sh/apps/redis-cluster/ Category: Caches & Key-Value (experimental) Upstream: Redis, https://redis.io/docs/latest/operate/oss_and_stack/management/scaling/ Template source: https://github.com/deployable-sh/stacks/tree/main/redis-cluster Redis Cluster shards your keyspace across multiple master nodes, so capacity and throughput scale horizontally instead of being capped by a single node. This template runs six nodes - three master shards, each with one replica - and a one-shot init that forms the cluster (verified locally: cluster_state ok, all 16384 slots covered). Each node announces its service hostname (cluster-announce-hostname + hostname endpoints) so clients and cross-slot redirects use DNS rather than raw pod IPs. The init waits for every node, then forms the cluster once and is idempotent on re-run. Use this when a single node is not enough. If you only need failover of one dataset (no sharding), redis-sentinel is simpler; for a single node, use redis. Footprint: 3.1 GiB RAM, 30 GB disk, 7 service(s). Miget sizing: Hobby 4 GiB plan at $25/mo; Professional 8 GiB at $85/mo. Managed-service comparison (June 2026): AWS ElastiCache cluster mode (6 nodes) ~$72/mo; Redis Cloud Flexible (sharded) (usage-based). FAQ: Q: Why is it experimental? A: Redis Cluster assumes stable node identities and is finicky on any per-pod platform. This template announces service hostnames so routing uses DNS, and it forms cleanly (smoke-tested), but a pod IP change can still need the cluster to re-meet. Treat it as a power-user topology. Q: Do my clients need changes? A: Clients must be cluster-aware (ioredis, redis-py, Lettuce, go-redis all have a cluster mode). They connect to any node at redis-node-1:6379 and follow MOVED/ASK redirects to the owning shard automatically. Q: Cluster or Sentinel? A: Cluster is for scale (sharding the keyspace across masters). Sentinel is for HA of a single dataset (failover, no sharding). If your data fits on one node, Sentinel is the simpler choice. ## Valkey Cluster URL: https://deployable.sh/apps/valkey-cluster/ Category: Caches & Key-Value (experimental) Upstream: Valkey, https://valkey.io Template source: https://github.com/deployable-sh/stacks/tree/main/valkey-cluster Valkey Cluster shards the keyspace across multiple master nodes for horizontal scale - the same design as Redis Cluster, BSD-licensed and Redis-protocol compatible. This template runs six nodes (three masters + three replicas) and a one-shot init that forms the cluster. Nodes announce their service hostname so clients and redirects use DNS instead of raw pod IPs; the forming init is idempotent. Use it when a single node`s RAM or throughput is not enough. For failover of a single dataset without sharding, valkey-sentinel is simpler; for one node, use valkey. Existing Redis Cluster client libraries work unchanged. Footprint: 3.1 GiB RAM, 30 GB disk, 7 service(s). Miget sizing: Hobby 4 GiB plan at $25/mo; Professional 8 GiB at $85/mo. Managed-service comparison (June 2026): AWS ElastiCache cluster mode (6 nodes) ~$72/mo. FAQ: Q: How does it relate to Redis Cluster? A: Valkey Cluster is the same sharding design and wire protocol, under the permissive BSD license. Redis Cluster client libraries connect to the valkey-node-* services unchanged. Q: Why experimental? A: Cluster mode expects stable node identities and is sensitive to address changes on per-pod platforms. Nodes announce service hostnames so routing uses DNS, but a pod IP change can require a re-meet - a power-user topology. Q: Cluster or Sentinel? A: Cluster shards for scale; Sentinel (valkey-sentinel) gives failover HA for a single dataset. Choose Cluster only when one node cannot hold the data or serve the throughput. ## MySQL URL: https://deployable.sh/apps/mysql/ Category: Databases Upstream: MySQL, https://www.mysql.com Template source: https://github.com/deployable-sh/stacks/tree/main/mysql MySQL is the most widely deployed open-source relational database, behind a huge share of web apps and frameworks. This template is a single MySQL 8.4 LTS node, configured entirely through the official image`s environment variables, with data on a volume and an app database and user created on first boot. It runs internal-only on Miget - apps in the same project connect at mysql:3306. Miget also offers managed MySQL as an addon (backups and failover handled for you), which is the better choice for most apps; this template is for full control of the version and configuration. For high availability, the catalogue has mysql-innodb-cluster (Group Replication) and percona-xtradb-cluster (synchronous multi-primary); for the MariaDB fork, see the mariadb templates. Footprint: 1 GiB RAM, 10 GB disk, 1 service(s). Miget sizing: Hobby 1 GiB plan at $7/mo; Professional 2 GiB at $22/mo. Managed-service comparison (June 2026): AWS RDS db.t4g.micro ~$15/mo; PlanetScale Scaler ~$39/mo. FAQ: Q: Should I use this or managed MySQL? A: For most apps, managed MySQL is less to operate (backups, failover, upgrades handled for you). Use this template when you need a specific version, custom configuration, or a private in-project database you fully control. Q: What does this save vs RDS? A: AWS RDS for MySQL starts around $15/month for the smallest instance and roughly doubles for Multi-AZ, plus storage and transfer. This is one flat plan on your own infrastructure. Q: How do I get high availability? A: A single node has a single point of failure. For HA use mysql-innodb-cluster (Group Replication with automatic failover) or percona-xtradb-cluster (synchronous multi-primary). ## MariaDB URL: https://deployable.sh/apps/mariadb/ Category: Databases Upstream: MariaDB, https://mariadb.org Template source: https://github.com/deployable-sh/stacks/tree/main/mariadb MariaDB is the community-developed fork of MySQL, drop-in compatible for the vast majority of applications and a popular default across CMSes, frameworks, and self-hosted apps. This template is a single MariaDB 11.8 node configured through the official image`s environment variables, with data on a volume. It runs internal-only on Miget - apps connect at mariadb:3306, and an app database and user are created on first boot. Miget offers managed MySQL for hands-off operation; run this when you specifically want MariaDB or full control of the configuration. MariaDB has a rich HA story, and the catalogue covers all of it: this standalone node, mariadb-replication (asynchronous primary/replica), and mariadb-galera (synchronous multi-primary cluster). Footprint: 1 GiB RAM, 10 GB disk, 1 service(s). Miget sizing: Hobby 1 GiB plan at $7/mo; Professional 2 GiB at $22/mo. Managed-service comparison (June 2026): AWS RDS for MariaDB db.t4g.micro ~$15/mo; Aiven for MySQL Startup ~$31/mo. FAQ: Q: Is MariaDB compatible with MySQL? A: For the large majority of applications, yes - same SQL, same wire protocol, same clients. There are version-specific differences in newer features, but typical CMS/app workloads run unchanged on either. Q: What HA options does the catalogue offer? A: Three modes: this standalone node, mariadb-replication (asynchronous primary/replica for read-scaling and hot standby), and mariadb-galera (synchronous multi-primary cluster where any node accepts writes). Q: Managed MySQL or this? A: Managed MySQL is simpler to operate. Choose this MariaDB template when you specifically want MariaDB, a particular version, or custom server configuration. ## MariaDB Replication URL: https://deployable.sh/apps/mariadb-replication/ Category: Databases Upstream: MariaDB, https://mariadb.com/kb/en/standard-replication/ Template source: https://github.com/deployable-sh/stacks/tree/main/mariadb-replication This is classic asynchronous MariaDB replication: one primary accepts writes and streams its binary log to a read-only replica. It is the standard topology for read-scaling (send reads to the replica) and for keeping a hot standby copy of your data. The official MariaDB image wires it from environment variables - the primary creates the replication user automatically, and the replica configures itself against the primary and starts replicating on first boot, so there are no init scripts. The replica is started read-only. Replication is asynchronous: the replica can lag slightly under load, and a failed primary does not auto-promote (that is a manual or external-tooling step). For synchronous, automatic multi-primary HA, use mariadb-galera. Footprint: 2 GiB RAM, 20 GB disk, 2 service(s). Miget sizing: Hobby 2 GiB plan at $13/mo; Professional 4 GiB at $43/mo. Managed-service comparison (June 2026): AWS RDS primary + read replica ~$30/mo. FAQ: Q: What is this good for? A: Read-scaling (route read-heavy queries to the replica to offload the primary) and keeping a hot standby copy of your database. It is the most common MySQL/MariaDB replication setup. Q: Does it fail over automatically? A: No. Asynchronous replication does not auto-promote the replica if the primary dies - promotion is a manual or tooling-driven step. For automatic failover use mariadb-galera (synchronous multi-primary). Q: How is the replica set up? A: Automatically. The official image creates the replication user on the primary and, on the replica, configures replication against MARIADB_MASTER_HOST and starts it on first boot - no scripts to run. ## Percona Server URL: https://deployable.sh/apps/percona-server/ Category: Databases Upstream: Percona Server for MySQL, https://www.percona.com/software/mysql-database/percona-server Template source: https://github.com/deployable-sh/stacks/tree/main/percona-server Percona Server for MySQL is a free, fully MySQL-compatible drop-in with extra instrumentation (expanded INFORMATION_SCHEMA and PERFORMANCE_SCHEMA tables), better diagnostics, and performance enhancements - the same SQL and clients as MySQL, with more visibility into what the server is doing. This template is a single node configured with the same MYSQL_* environment variables as the MySQL template, internal-only on Miget (apps connect at percona:3306), with an app database and user created on first boot. Choose Percona Server when you want its instrumentation and tuning for a single database; for synchronous multi-primary high availability, the catalogue has percona-xtradb-cluster. Footprint: 1 GiB RAM, 10 GB disk, 1 service(s). Miget sizing: Hobby 1 GiB plan at $7/mo; Professional 2 GiB at $22/mo. Managed-service comparison (June 2026): AWS RDS db.t4g.micro ~$15/mo. FAQ: Q: How is it different from plain MySQL? A: It is a drop-in replacement: same SQL, protocol, and clients, but with additional instrumentation, diagnostics, and performance features. Apps do not need any changes to run against it. Q: Does it use the same configuration as MySQL? A: Yes - this template uses the same MYSQL_ROOT_PASSWORD / MYSQL_DATABASE / MYSQL_USER / MYSQL_PASSWORD variables, so switching between the mysql and percona-server templates is straightforward. Q: How do I run it highly available? A: Use percona-xtradb-cluster, which is synchronous multi-primary HA (Galera-based) built on Percona Server. This standalone template is a single node. ## Percona XtraDB Cluster URL: https://deployable.sh/apps/percona-xtradb-cluster/ Category: Databases (experimental) Upstream: Percona XtraDB Cluster, https://www.percona.com/software/mysql-database/percona-xtradb-cluster Template source: https://github.com/deployable-sh/stacks/tree/main/percona-xtradb-cluster Percona XtraDB Cluster (PXC) is synchronous, multi-primary MySQL high availability built on Galera. All three nodes accept reads and writes, and a transaction is replicated to every node before commit returns - so there is no replica lag and any single node can fail without data loss. Clustering is driven entirely by the image`s environment variables: the first node bootstraps the cluster and the others join it, syncing via SST. It is the MySQL-side counterpart to the catalogue`s mariadb-galera template. It is marked experimental because synchronous clusters need operational care - notably, a full cold start may require bootstrapping the most-advanced node first. For asynchronous primary/replica instead, see mariadb-replication; for a single node, percona-server. Footprint: 3 GiB RAM, 30 GB disk, 3 service(s). Miget sizing: Hobby 4 GiB plan at $25/mo; Professional 8 GiB at $85/mo. Managed-service comparison (June 2026): AWS RDS Multi-AZ ~$30/mo; Aiven for MySQL Business (HA) ~$80/mo. FAQ: Q: How is this different from primary/replica replication? A: PXC is synchronous and multi-primary: writes commit on all nodes together, so there is no replica lag and any node accepts writes. Primary/replica (mariadb-replication) is asynchronous - one writable primary, replicas that can lag and need manual promotion. Q: PXC or mariadb-galera? A: They are the same class of cluster (both Galera-based synchronous multi-primary) on different forks - PXC on Percona/MySQL, mariadb-galera on MariaDB. Pick the one matching the database your app targets. Q: Why experimental? A: Synchronous clusters are sensitive to startup ordering: a full cold start can require bootstrapping the most-advanced node first to avoid split-brain. Everything is wired and validated, but it needs the operational care any Galera cluster does. ## MySQL InnoDB Cluster URL: https://deployable.sh/apps/mysql-innodb-cluster/ Category: Databases (experimental) Upstream: MySQL Group Replication, https://dev.mysql.com/doc/refman/8.4/en/group-replication.html Template source: https://github.com/deployable-sh/stacks/tree/main/mysql-innodb-cluster MySQL InnoDB Cluster is the native MySQL high-availability stack, built on Group Replication: a group of nodes that replicate synchronously, elect a primary automatically, and fail over without manual intervention. This template runs three nodes and a one-shot init that configures the recovery accounts and forms the group. Group Replication is the fiddliest topology in this catalogue - it depends on stable inter-node addressing (each node`s group address, the seeds list, and the IP allowlist) and is sensitive to node-identity changes. The nodes are configured with the loose- option prefix so they boot cleanly before the plugin loads, and the init is idempotent. It was smoke-tested locally to a three-member ONLINE group. This template ships no MySQL Router (its 8.4 image is not published on Docker Hub), so apps connect to a node directly or you add a Router alongside. For simpler synchronous HA, percona-xtradb-cluster and mariadb-galera are easier to operate. Footprint: 3.3 GiB RAM, 30 GB disk, 4 service(s). Miget sizing: Hobby 4 GiB plan at $25/mo; Professional 8 GiB at $85/mo. Managed-service comparison (June 2026): AWS RDS Multi-AZ ~$30/mo. FAQ: Q: How is this different from Percona XtraDB Cluster? A: Both give synchronous, automatic-failover HA. This uses MySQL`s own Group Replication (the InnoDB Cluster engine) in single-primary mode; PXC and mariadb-galera use Galera multi-primary. Group Replication is the native MySQL stack but the most operationally sensitive of the three. Q: Why no MySQL Router? A: The MySQL Router 8.4 image is not published on Docker Hub, so this template omits it - apps connect to a node directly (discover the primary from performance_schema.replication_group_members) or you run a Router alongside. The group itself provides the HA. Q: Why experimental? A: Group Replication depends on stable inter-node addresses and is sensitive to identity changes on a per-pod platform. It is wired with the loose- option prefix and an idempotent init, and was smoke-tested to a 3-member ONLINE group, but it needs more operational care than the other HA templates.