Deploy

One click. Your server, running your app, on the public internet.

You ran the audit and saw the issues in your Dockerfile, Compose file, or deployment setup. This page explains exactly what happens when TryDirect deploys the same code — the server it provisions, the reverse proxy it configures, the SSL cert it fetches, and what you need to have ready before you start.

What happens when you click Deploy

No black box. This is the exact sequence — same whether you use the web UI or run stacker deploy from the command line.

0:00
You click Deploy
Web UI, or `stacker deploy` from the command line. Same code path either way.
0:10
Server provisioned
TryDirect calls your cloud provider (Hetzner, DigitalOcean, AWS, Linode, Vultr) with your own API key. A fresh Ubuntu box appears in your cloud account, not ours.
1:30
Docker + Nginx Proxy Manager installed
The server boots, Docker is installed, and Nginx Proxy Manager (NPM) comes up ready to receive traffic on ports 80 and 443. Only SSH, HTTP, and HTTPS are publicly reachable.
3:00
Your stack pulled and started
TryDirect generates a hardened docker-compose.yml from your stacker.yml, pulls the images, generates missing secrets, and starts every service. Container healthchecks must pass before continuing.
6:00
Reverse proxy wired, SSL issued
NPM is configured to route your domain to the right container. Let's Encrypt is asked for a certificate via HTTP-01. Certificate arrives, HTTPS is live.
8:00
Live URL delivered
You get a working https://your-domain URL in the dashboard, plus a link to real-time deploy logs. The Status Panel starts tracking uptime and resource use from second one.

End-to-end median: ~8 minutes for a fresh cloud deploy. Re-deploys of an existing stack: under 60 seconds.

Before you deploy: three things you need

Not a signup form. Practical prerequisites — get these ready and the deploy just works.

1.A domain that points at your future server

Set an A record for your subdomain (e.g. app.yourcompany.com) to a placeholder IP, or ask TryDirect to pick a *.stacker.my subdomain for you. DNS must resolve before SSL can be issued.

Skip this and Let's Encrypt validation fails.

2.One of: cloud API key OR a Linux server

Bring your own Hetzner / DigitalOcean / AWS / Linode / Vultr API key — TryDirect provisions into your account, at your cloud rates. Or point at any Linux server with SSH access if you already have one.

TryDirect never holds your infrastructure and never bills you for compute.

3.Two minutes to fill in template-specific secrets

Databases need a password, admin users need an initial credential, some services need an API key. The deploy UI shows exactly which ones — everything else is generated for you.

Secrets are stored in TryDirect Vault, never in plaintext in git or on disk.

Two ways to deploy — same result

Pick your interface. The generated configuration, the security defaults, the running system — all identical.

Web UI

Best for exploring the catalog and non-CLI folks.

Browse /applications, pick a stack (Ghost, Umami, Nextcloud, Dify, …)
Enter a domain, choose a cloud provider, paste API key
Fill any template-specific secrets
Click Deploy — watch the live log in the dashboard

Browse the marketplace →

Stacker CLI

Best for repeatable deploys, CI/CD, and infra-as-code teams.

git clone github.com/trydirect/awesome-selfhosted-stacker
cd stacker-projects/<any-of-67-templates>
cp .env.example .env && ./scripts/generate-secrets.sh
stacker deploy — same result as clicking through the UI

Browse 67+ templates on GitHub →

Every audit issue → fixed on deploy

The audit checkers flag common production risks. Here's how each is handled when you deploy through TryDirect.

Dockerfile issues

Missing HEALTHCHECK, running as root, oversized base image, no multi-stage build.

Templates ship with pinned base images, non-root users, HEALTHCHECK, and multi-stage builds by default.

Compose issues

Ports bound to 0.0.0.0, missing restart policies, no resource limits, secrets in env files.

Generated Compose binds DB ports to 127.0.0.1, sets restart: always, applies CPU/memory limits, pulls secrets from Vault.

Public exposure risks

Admin panels reachable from the public internet; unnecessary open ports.

NPM fronts everything on 443. App/DB/queue ports are internal-only. IP allowlisting per subdomain is one setting.

Image vulnerabilities (CVEs)

Base images with known CVEs; no scan gate before deploy.

Trivy scans every image on build. Critical CVEs block the deploy; you see the report before anything ships.

Readiness gaps

No healthchecks, no backups, no monitoring, no SSL automation.

Auto Let's Encrypt, container healthchecks on every service, backup volume conventions, Status Panel wired in.

Cost surprises

Oversized instances, unused resources, no visibility into monthly burn.

TryDirect sizes servers to your compose declaration and shows per-provider pricing before you deploy.

What you get on the other side

Concrete artifacts, not slogans. Everything below is available from the dashboard the moment deploy finishes.

✅ A running https:// URL, ready to log into
✅ Live deploy log + persistent audit log
✅ SSH access to the server (it's yours)
✅ Status Panel dashboard: CPU, RAM, disk, container health
✅ Auto-renewing Let's Encrypt certificates
✅ Named docker volumes ready for backup
✅ The exact docker-compose.yml TryDirect generated — yours to keep

FAQ

Do I need to fix the audit issues myself before deploying?

No. When you deploy the same code via TryDirect, our stack templates and generated configurations correct the common issues automatically. Anything template-specific (a secret you have to provide) is flagged in the deploy UI.

Do I pay TryDirect for cloud costs?

No. You connect your own cloud provider account. Provider charges go directly to you at whatever rate you already pay them; TryDirect only charges the platform subscription (free tier covers your first deploy).

What if DNS isn't set up yet when I deploy?

Deploy proceeds, but Let's Encrypt will fail to issue an SSL certificate. Fix by pointing DNS at the server IP shown in the dashboard, then re-run the SSL step from the deploy screen. The container itself stays up the whole time.

Can I use TryDirect without signing up?

The Stacker CLI is open source and free. `stacker deploy` from a template in awesome-selfhosted-stacker runs locally, on any Linux server you SSH to, or against a cloud provider with your own key — no TryDirect account required. The web UI, one-click cloud provisioning, and Status Panel dashboard require an account.

Where do my secrets live?

TryDirect Vault (encrypted at rest, scoped per-service, injected into containers at runtime). They never appear in git, in the generated compose file on disk, or in the dashboard UI in plaintext. You can rotate them per-service without redeploying the whole stack.

Can I SSH into the server?

Yes — it's your server. TryDirect adds its own SSH key for Status Panel and future deploys; you keep root and can add your own keys any time. TryDirect never removes the box, changes billing, or locks you out.

What if I have a custom stack that isn't in the catalog?

Paste your docker-compose.yml or Dockerfile in the Stack Builder. TryDirect audits it, warns about issues, and generates the production-ready deployment configuration. Or write a stacker.yml by hand — the format is documented.

How is this different from just running docker-compose up on a server?

docker-compose up runs your containers. It doesn't provision the server, install Docker, set up a reverse proxy, request SSL, wire healthchecks, monitor uptime, or generate secrets. TryDirect handles all of those as part of every deploy.

How do I update the app after deploy?

Change the image tag in stacker.yml (or click Update in the dashboard) and re-deploy. Rolling restart, healthcheck gate, rollback if the new version fails to start. Same command, no downtime for stateless services.