# FAQ

Frequently asked questions about DeployAlly.

# General

# What is DeployAlly?

DeployAlly is a declarative deployment platform for containers. You describe what you want to run (template + inputs); the platform handles how (generating secrets, resolving dependencies, configuring Traefik, waiting for health).

# Which operating systems are supported?

The CLI runs on Linux x86_64 and aarch64 (a static musl binary, zero dependencies). Target servers need Linux with Docker 20.10+.

# Do I need to know Docker to use it?

Basic familiarity helps, but it isn't required. Templates abstract the configuration — you supply a domain and admin email, and sensible defaults fill in the rest.

# Is DeployAlly free?

There are free and paid plans. The free plan includes 1 server, the public template catalog, and 60 API requests per minute. Paid plans offer more servers, premium templates, and higher limits.

# Templates

# Which templates are available?

Eleven templates are currently published:

• Applications: memos, uptime-kuma, vaultwarden, n8n, wordpress, postal
• Assets: mariadb, mysql, postgresql, redis
• Network: traefik

See the full list in Templates.

# Can I create my own templates?

Yes. Use deployally template new to scaffold one from an archetype:

deployally template new \
  --archetype application \
  --species my-app \
  --image my-repo/my-app:1.0 \
  --port 8080 \
  --out my-app.yaml

And validate with:

deployally validate --species my-app --templates-dir .

See Templates and Reflang Reference.

# How do I update a template?

Published templates are immutable (each one carries a SHA256 hash of its spec). To change one:

1. Edit the YAML
2. Bump the version field
3. Publishing computes a new hash
4. New deploys use the new version; existing deploys stay on the previous one

# Can I modify a catalog template?

Remote templates aren't modified in place. To customize:

1. Take the template as a base
2. Edit it locally
3. Use it with --source local --templates-dir <folder>

# Deployments

# How long does a deploy take?

It depends on image size and network:

• First deploy (image pull required): 1-5 minutes
• Subsequent deploys (image cached): 10-30 seconds
• With asset auto-provisioning: + time for the asset to become healthy (~30-60s for a database)

# How does asset auto-provisioning work?

When you use --provision-missing-assets, the deployer:

1. Detects dependencies declared in the template's needs
2. For each unmet needs, picks the first option in the list
3. Deploys the asset with variant default: true
4. Waits for health with exponential backoff (3→15s, up to 5 attempts)
5. Continues with the consumer deploy

# What happens if the deploy fails?

The previous container (if any) keeps running. The standard blue-green strategy:

1. New container created in parallel
2. Healthcheck runs
3. If healthy, Traefik routes traffic over
4. Old container removed

Healthcheck failure = automatic rollback.

# Can I deploy across multiple servers?

Yes. Each server runs the CLI independently, or you can drive it via the API/dashboard with a per-deploy server_id.

# What does a profile do?

A profile tunes resources (memory, CPU, pool size) per environment:

deployally deploy --species mysql --instance-uid db-001 \
  --profile production --apply

Available profiles vary by template. Common ones: minimal, development, production.

# Security

# How are passwords stored?

• Locally: /opt/deployally/manifests/<uid>/secrets.json with permission 600
• On the server: encrypted with AES-256-GCM in the vault
• In transit: HTTPS TLS 1.3 with CLI-side certificate pinning

Passwords never appear in plaintext in logs or the database.

# Are API keys secure?

Yes:

• Generated with cryptographic entropy
• Stored as a SHA-256 hash on the server
• Transmitted only over HTTPS
• Revocable at any time
• Support IP allowlists

# How do generated secrets work?

Templates declare secrets with chained providers:

secrets:
  DB_PASSWORD:
    provider: input
    generate:
      type: alnum
      length: 32

The engine tries each provider in order: if input was supplied, it's used; otherwise it runs generate.alnum(32). The result is a value that's unique per instance, persisted to disk with chmod 600.

# What is Reflang?

Reflang is the substitution language used in templates. It lets you reference values (${input.X}, ${secrets.X}), generate values at runtime (${random.hex(32)}), and apply logic (${if(input.DEBUG, 'debug', 'info')}). See Reflang Reference.

# Infrastructure

# Do I need a dedicated server?

No. It works on a VPS, cloud, dedicated host, or local machine. Minimum: 1 GB RAM, 10 GB disk, Docker installed.

# Does DeployAlly manage DNS?

No. You configure DNS pointing at the server; DeployAlly handles the rest:

• HTTPS routing via Traefik
• Automatic Let's Encrypt certificates
• DNS preflight before deploys (avoids broken deploys)

# Can I use it without internet?

Partially. Use --offline to force the local-only flow (no network fetch). Templates need to be in the cache or in --templates-dir. Auto-provisioning works only if the images are already in Docker.

# How do I back up?

Data lives in Docker volumes (/var/lib/docker/volumes/). We recommend:

1. Regular volume backups
2. Exporting the instance manifest (which contains the rendered spec + secrets)
3. Use dedicated tools (BackupAlly, restic, rsync)

# CLI

# How do I update the CLI?

deployally self-update

Release candidate channel:

deployally self-update --rc

The command downloads the new version, validates it, swaps the binary, and restores the backup if the check fails.

# How do I find out which version I have?

deployally --version

# Where does the configuration live?

/opt/deployally/
├── deployally               # binary
├── config.yaml              # global config (optional)
└── manifests/<uid>/         # per-instance state

# Troubleshooting

# A container doesn't start — what now?

1. Check logs: docker logs <container-id>
2. Check health: docker inspect <container-id> --format '{{json .State.Health}}'
3. Inspect the rendered manifest: cat /opt/deployally/manifests/<uid>/manifest.yaml

See Troubleshooting for more scenarios.

# How do I report a bug?

1. Collect deployally --version, logs, manifest, and the output of deployally validate
2. Open an issue at github.com/devborlot/deployally-client
3. Or email: support@deployally.com

# Where can I find more help?

• Documentation
• Troubleshooting
• Reflang Reference
• CLI Reference

# Billing and Plans

# How does billing work?

The Free plan is free with usage limits. Paid plans are monthly and you choose the limits.

# Can I cancel at any time?

Yes, from the dashboard. Your data remains accessible for 30 days after cancellation.

# What happens if I hit the limit?

Requests beyond the limit return 429 Rate Limited. Containers keep running normally — only the API is throttled.