Everything you need to deploy and manage apps on TinyPod.
Sign up for free — no credit card required. You get a 3-day trial with 1 CPU core, 1GB RAM, and 1GB storage to test the platform.
Browse 200+ one-click apps (Postgres, Redis, WordPress, n8n, etc.). Pick one, choose your resources (CPU, RAM, storage), and deploy in under 60 seconds. Every app is pre-configured and production-ready.
Use 170+ multi-container templates (Supabase, Appwrite, Penpot, etc.) for full-stack deployments. Templates include all dependencies — databases, caches, workers — pre-configured and networked together.
Every app gets a free URL like yourapp.tinypod.app with automatic HTTPS via Caddy. Find your URL on the dashboard immediately after deploy. You can add a custom domain later.
Your dashboard shows all running pods and projects, resource usage, subscription status, and quick actions. Click any pod to view logs, manage settings, or trigger a restart.
Go to Projects → New → From GitHub. Paste your repository URL (public or private) and select a branch. TinyPod will clone and analyze your project.
Choose your build strategy: Dockerfile (use your own Dockerfile), Nixpacks (auto-detects language — supports Node.js, Python, Go, Rust, Ruby, PHP, Java, .NET, and more), or Buildpacks (specify a base image, build command, and start command manually).
If your repo contains a Dockerfile, TinyPod uses it directly. Multi-stage builds are supported. The build runs on your deployment server, so large builds work fine — no size limits.
Nixpacks auto-detects your language, framework, and dependencies. It reads package.json, requirements.txt, go.mod, Cargo.toml, etc. and generates an optimized container image without any Dockerfile.
For custom setups: specify a base image (e.g., node:20-alpine), a build command (e.g., npm run build), and a start command (e.g., npm start). TinyPod generates a Dockerfile from these inputs.
Push to your branch and TinyPod rebuilds and redeploys automatically. You can also trigger manual redeploys from the project settings page.
By default, the entire repo is used as build context. If your Dockerfile is in a subdirectory, set the build context path in project settings (e.g., ./backend).
Go to Projects → New → Multi-Container. Paste your docker-compose.yml content directly. TinyPod parses all services, images, ports, environment variables, volumes, and dependencies automatically.
If your repo has a docker-compose.yml or compose.yml at the root, TinyPod detects it automatically. Services with build: directives are built on-server; services with image: are pulled directly.
TinyPod reads your compose file and detects each service's image, exposed ports, environment variables, depends_on relationships, volumes, and commands. Database services (postgres, mysql, redis, mongo) are auto-detected as worker services.
After parsing, review each service: change images, override ports, edit environment variables, adjust CPU/RAM/storage per service. Add or remove services as needed before deploying.
All services in a compose project are deployed in the same Podman pod. They communicate via localhost — no special networking config needed. Use the service name as hostname for inter-service communication.
Named volumes from your compose file are mapped to persistent storage on the server. Data survives container restarts and redeployments.
BYOVPS lets you connect your own servers to TinyPod. You get the full management dashboard — one-click deploys, SSL, reverse proxy, logs — on infrastructure you control. $5/server/month, unlimited apps.
Any Linux VPS with SSH access. Ubuntu 22.04+ or Debian 12+ recommended. Minimum 1 GB RAM, 10 GB disk. Root or sudo access required for initial setup.
Go to Dashboard → My Servers. Enter your VPS name, IP address, and SSH private key (base64-encoded). TinyPod tests the SSH connection, then installs Podman (rootless containers) and Caddy (reverse proxy with automatic SSL).
Generate an SSH key pair: ssh-keygen -t ed25519. Add the public key to your VPS (~/.ssh/authorized_keys). Base64-encode the private key: cat ~/.ssh/id_ed25519 | base64 -w0. Paste this into TinyPod.
Point your domain to your VPS. Add two DNS records: a wildcard A record (* → your VPS IP) and a root A record (@ → your VPS IP). This enables automatic subdomains like app-name.yourdomain.com for every app you deploy.
Any VPS with SSH access works: Hetzner, DigitalOcean, Linode, Vultr, OVH, AWS EC2, Google Cloud, Azure, Oracle Cloud, Contabo, Netcup, and more.
TinyPod installs: Podman (rootless container engine, no Docker daemon needed), Caddy (reverse proxy with automatic Let's Encrypt SSL), and shared database containers (Postgres, MySQL, Redis) if you deploy apps that need them.
Connect as many servers as you need. Each server operates independently. Deploy different apps to different servers, or use multiple servers for different environments (staging, production).
Services within the same project run in the same Podman pod and communicate via localhost. For example, your web app connects to its database at localhost:5432 — no external networking needed.
Caddy handles all incoming traffic. Each public-facing service gets a subdomain (app-name.tinypod.app or app-name.yourdomain.com). Caddy terminates TLS and proxies to the correct container port.
Each service specifies a container port. Caddy maps this to HTTPS on port 443 automatically. For non-HTTP services (databases, Redis), ports are only accessible internally — not exposed to the internet.
Within a pod, services reference each other by localhost and port. For cross-project communication on the same server, use the container's IP address or set up environment variables with the target service URL.
Web services (serviceType: web) get a public subdomain and are accessible from the internet. Worker services (serviceType: worker) are internal-only — they run but don't get a public URL. Use this for databases, caches, background workers, etc.
TinyPod runs shared PostgreSQL, MySQL, and Redis instances on each server. When you deploy an app that needs a database, TinyPod creates a dedicated database and user within the shared instance automatically.
Connection credentials (host, port, database name, username, password) are injected as environment variables into your app container. Check your pod's Settings tab to see them.
Shared PostgreSQL 17 instance. Each app gets its own database and user. Connect via DATABASE_URL or individual PGHOST, PGPORT, PGDATABASE, PGUSER, PGPASSWORD variables.
Shared MySQL 8 instance. Each app gets its own database and user. Connect via MYSQL_HOST, MYSQL_PORT, MYSQL_DATABASE, MYSQL_USER, MYSQL_PASSWORD variables.
Shared Redis 7 instance. Apps share the same Redis server but can use key prefixes for isolation. Connect via REDIS_URL (redis://shared_redis:6379).
For apps that need their own database container (e.g., specific version, custom config), deploy using a multi-container template or Docker Compose — each service gets its own container with full control.
Shared databases are included in the daily automatic backup. You can also trigger manual backups. Backups include a full database dump that can be restored with one click.
Set DATABASE_URL or equivalent environment variables in your pod settings to connect to any external database (Neon, PlanetScale, Supabase, AWS RDS, etc.).
Each container gets persistent storage mapped to a directory on the host server. Data in these volumes survives container restarts, redeployments, and updates.
Set storage per service when deploying. Storage is allocated from the server's disk. You can increase storage anytime from the pod settings — changes apply on next restart.
Docker Compose deployments preserve named volumes from your compose file. They're mapped to host directories and persist across deployments.
Most apps store data in standard paths (/data, /var/lib, /config, etc.). TinyPod mounts persistent volumes to these paths automatically based on the app's configuration.
Hosted platform: storage counts toward your plan limits (75GB per server). Add more servers to increase storage. BYOVPS: unlimited storage — limited only by your server's disk space.
View real-time logs for any pod from its detail page. Logs show stdout and stderr from your container. Use the logs tab to debug startup issues, errors, or track request patterns.
Logs are retained for 7 days on the hosted platform. On BYOVPS, logs persist as long as your server has disk space. Download logs from the dashboard for long-term storage.
The dashboard shows CPU usage, memory consumption, and storage used per pod. Check these metrics to right-size your resources or detect issues.
Each pod shows its current status: creating, running, stopped, suspended, or error. Status updates in real-time on the dashboard.
Restart a pod from its detail page to apply environment variable changes. Rebuild re-pulls the image (or re-builds from source) and creates a fresh container with the same volumes.
TinyPod periodically checks if your containers are running and responsive. If a container crashes, it's automatically restarted (Podman's restart policy).
For web services, TinyPod checks the HTTP endpoint. If your app returns 5xx errors consistently, it's flagged as unhealthy on the dashboard.
For BYOVPS servers, TinyPod checks SSH connectivity and server responsiveness. Status is shown on the My Servers page: healthy, degraded, or unreachable.
Containers are configured with always restart policy. If your app crashes, Podman restarts it automatically within seconds. Persistent crashes are flagged in the dashboard.
Every app gets a free subdomain: yourapp.tinypod.app (hosted) or yourapp.yourdomain.com (BYOVPS). HTTPS is automatic and requires no configuration.
Go to your pod's Settings tab → Custom Domain. Enter your domain (e.g., app.example.com). TinyPod generates a CNAME record for you to add to your DNS provider.
Add a CNAME record pointing your custom domain to your pod's default URL. For apex domains (example.com without www), use an ALIAS or ANAME record if your DNS provider supports it, or use a subdomain instead.
Caddy provisions Let's Encrypt SSL certificates automatically for all domains. Certificates renew automatically before expiry. No manual setup needed — ever.
If using Cloudflare, set the DNS record to DNS-only mode (gray cloud icon, not orange). This lets Caddy provision its own SSL. If you want Cloudflare's proxy (orange cloud), set SSL mode to Full (Strict) in Cloudflare.
BYOVPS uses wildcard DNS. Add * A record pointing to your VPS IP. Every app you deploy automatically gets a subdomain under your domain — no per-app DNS config needed.
Every pod is backed up daily at 3:00 AM UTC. Backups include container volumes (your app data), database dumps (if using shared databases), and environment variable configuration.
Backups are stored on Cloudflare R2 (S3-compatible object storage). They're encrypted at rest and retained for 30 days. BYOVPS backups are stored on the server itself by default.
Trigger a backup anytime from your pod's Backups tab. Useful before making breaking changes, updating environment variables, or migrating.
Click restore on any backup to roll your pod back to that point. The current container is stopped, volumes are replaced with the backup data, and the container restarts. Takes seconds for small apps, minutes for large datasets.
Download any backup as a compressed archive. Use this for local testing, migrating to another server, or long-term archival.
A project groups related services that work together. For example: a web frontend, API backend, PostgreSQL database, and Redis cache — all in one project, networked together, managed as a unit.
Go to Projects → New. Choose your deploy method: GitHub repo, Docker Compose, or multi-container template. Each service in the project can have its own image, resources, and environment variables.
Web services get a public URL and handle HTTP traffic. Worker services run in the background (databases, caches, queue processors, cron jobs). Cron services run on a schedule.
Add more services to an existing project from the project detail page. Useful for adding a cache, worker, or database to a running application.
Services can depend on each other (depends_on in Docker Compose). TinyPod starts services in the correct order — databases before apps, caches before workers.
Postgres, MySQL, and Redis are available as shared infrastructure on each server. Each app gets its own database within the shared instance. No separate container needed for common database needs.
Each service has configurable CPU (in cores), RAM (in MB), and storage (in GB). Set these when deploying, adjust anytime from the pod settings.
Set from 0.1 cores (shared, good for low-traffic apps) up to your plan limit. Most apps run well on 0.25–0.5 cores. Total CPU across all apps counts toward your server limits.
Set from 128 MB up to your plan limit. Node.js apps typically need 256–512 MB. Java/JVM apps need 512 MB–1 GB. Total RAM across all apps counts toward your server limits.
Persistent disk space for your app's data. Database-heavy apps (Nextcloud, Immich, GitLab) need more storage. Storage is persistent across restarts. Total storage counts toward your server limits.
Increase CPU, RAM, or storage from pod settings. Changes take effect on next restart. No data loss — volumes are preserved.
Decrease CPU or RAM anytime. Storage can only be increased, not decreased (to prevent data loss). Reduce storage by redeploying with a new volume.
Each server gives you 4 CPU cores, 8GB RAM, and 75GB NVMe storage. Resources stack — 2 servers = 8 cores, 16GB RAM, 150GB. Add servers from your billing page to increase limits.
Go to your pod's Settings tab → Environment Variables. Add key-value pairs. Common variables: DATABASE_URL, API_KEY, NODE_ENV, PORT, SECRET_KEY.
When deploying from the App Catalog, required variables are pre-filled with sensible defaults (database credentials, random secrets, etc.). Review and customize before deploying.
Edit any variable from the pod settings. Click save, then restart your pod for changes to take effect. The old container is stopped and a new one starts with the updated variables.
Environment variables are encrypted at rest in the database. They're decrypted only when injected into the container at startup. Never logged or exposed in the dashboard beyond the settings page.
Reference other variables using $VARIABLE_NAME syntax. For example: DATABASE_URL=postgres://$DB_USER:$DB_PASS@localhost:5432/$DB_NAME.
TinyPod automatically injects: PORT (the container's exposed port), HOSTNAME (the pod's subdomain), and database connection variables when using shared databases.
After connecting a GitHub repo, TinyPod can listen for push events. When you push to the configured branch, a new build and deploy is triggered automatically.
Trigger a redeploy from the project settings page at any time. This re-pulls the latest image (or rebuilds from source) and restarts the container.
For apps using Docker Hub or GHCR images, enable auto-update to pull the latest image tag periodically and redeploy when a new version is available.
If a deploy breaks your app, use the backup restore feature to roll back to the previous working state. Or redeploy with the previous image tag.
Go to Dashboard → API Keys to create new keys. Each key is scoped to your account and can manage all your pods and projects programmatically.
Include your API key in the Authorization header: Authorization: Bearer your-api-key. All API endpoints require authentication.
The API supports: listing pods, creating/deleting pods, managing environment variables, triggering deploys, viewing logs, and managing VPS servers.
API requests are rate-limited to 100 requests per minute per key. Exceeding this returns a 429 response. Contact support if you need higher limits.
Delete an API key from the dashboard to immediately revoke access. Generate a new key if you suspect one has been compromised.
Go to Teams to create a team. Invite members by email. Team members can view and manage shared pods and projects.
Owner: full control including billing and team management. Member: can deploy, manage, and restart pods. Viewer: read-only access to dashboards and logs.
Teams share a subscription and VPS servers. All team members can deploy to the team's servers and view all team pods.
Each user has a personal workspace and can also belong to teams. Switch between personal and team context from the dashboard.
$5/server/month. Each server gives you 4 CPU cores, 8GB RAM, and 75GB NVMe storage. Add more servers to scale your resources.
3-day free trial with no credit card required. Limited to 1 CPU core, 1GB RAM, and 1GB storage. After the trial, subscribe at $5/server/mo to keep your apps running.
Your apps are stopped (not deleted). Data is preserved. Subscribe and your apps resume exactly where they left off.
No bandwidth charges, no per-deploy fees, no premium support tiers, no egress fees. $5/server/month covers everything.
Cancel anytime. Your subscription stays active until the end of the billing period. No contracts, no cancellation fees.
Check the container logs for error messages. Common causes: missing environment variables, wrong port configuration, or the image doesn't exist. Verify your env vars match what the app expects.
For GitHub deploys: check that your Dockerfile or package.json is correct. Nixpacks logs show which buildpack was detected. Common issues: missing dependencies, wrong Node/Python version, or build command errors.
Your app's container port doesn't match the port Caddy is proxying to. Check the PORT environment variable matches the port your app listens on. Restart the pod after fixing.
Verify your DNS records are correct (CNAME for subdomains, A record for apex). Wait up to 10 minutes for DNS propagation. If using Cloudflare, set DNS-only mode (gray cloud).
DNS changes can take 1–10 minutes (most providers) or up to 48 hours (some registrars). Use dig yourapp.example.com or nslookup to check if records have propagated.
Verify: correct IP address, SSH key is base64-encoded properly, port 22 is open, and the public key is in ~/.ssh/authorized_keys on the server. Test manually: ssh -i your_key root@your-ip.
The app is crashing on startup. Check logs for the error. Common causes: database not ready yet (add a depends_on or retry logic), out of memory (increase RAM), or config error.
If your pod is killed with exit code 137, it ran out of memory. Increase RAM from pod settings. Java/JVM apps: set -Xmx to 70% of allocated RAM. Node.js: increase --max-old-space-size.
Check CPU and memory usage on the dashboard. If CPU is consistently at 100%, increase CPU cores. If memory is near the limit, increase RAM. For database-heavy apps, ensure you have enough storage IOPS.
Can't solve it? Email us at support@tinypod.app or use the Contact page. Include your pod ID and any error messages for faster resolution.