Git integration and signed webhooks
Connect GitHub, GitLab or Bitbucket in one click. Each push sends a webhook that starts an isolated build right away.
Webhook payloads are verified with SHA-256 signatures; repository tokens stay private.
Build and deploy lifecycle
How Deployxa builds and deploys.
From the webhook on your push to a health-checked release with HTTPS: every step of the pipeline, in order.
01 / Pipeline
Four stages, every push.
Isolated build sandbox
Every push gets its own build environment. The builder restores dependency caches, compiles your app and packages it as static output or a container image.
Build layers are cached, so repeat builds skip work that has not changed.
Databases and secrets
When your project uses a database, Deployxa provisions it, runs your migrations and injects the connection credentials.
Secrets are injected into the build and runtime environment, never written to build logs.
Edge routing and TLS
The release goes out behind the edge proxy with a Let's Encrypt certificate. Custom domains and subdomains are mapped automatically.
Certificates renew in the background; HTTPS is on from the first request.
02 / Trace
Follow one deploy, line by line.
This is what a typical push looks like in the deploy log: webhook, build, checks, secrets, migrations, TLS and the health-checked switch.
- Readable logs for every stage
- Failures stop the rollout before users see them
- Same pipeline on every plan
$ git push origin main✓ Webhook received · main · signature verified→ Build sandbox ready · restoring cache→ npm run build vite building for production… done→ tsc --noEmit · 0 errors✓ Secrets injected · not written to logs→ Running migrations on attached PostgreSQL✓ TLS certificate issued (Let's Encrypt)✓ Health check 200 OK · traffic switched✓ Live at https://my-app.deployxa.online
03 / Safety
Built to fail safely.
Container isolation
Each app runs in its own container with dedicated resource limits and port boundaries, so workloads do not interfere with each other.
Fast rollbacks
Previous releases are kept, so rolling back switches traffic to a known-good version without rebuilding.
Health-aware routing
Health endpoints are checked continuously and traffic is only sent to instances that pass.
04 / Rollbacks
Every release is a place you can go back to.
Each deployment keeps its commit, logs and status in the release history. Rolling back points traffic at an earlier successful release, instantly while it is still warm, or from its cached image after that.
- One click on any successful release in the dashboard
- deployxa rollback previous from the terminal
- No rebuild while the warm standby window is open
- 01v42 · main · 7e1c0d9live
- 02v41 · main · 3b9a1f2warm standby
- 03v40 · main · c04d8e7cached image
- 04v39 · pr-118preview
05 / Preview vs production
Try changes before your users do.
| Preview | Production | |
|---|---|---|
| Triggered by | Opening or updating a pull request | A push to your production branch, the CLI or a manual redeploy |
| URL | Its own preview URL | Your custom domains and the project .deployxa.online URL |
| Isolation | Separate container and routes | The live release, health-checked before traffic moves |
| Lifetime | Removed when the PR is closed or merged, or torn down by hand | Until the next release replaces it |
| Going live | deployxa promote ships the latest successful preview | Already live; roll back if needed |
| Plans | Pro, Team, Business and Enterprise | Every plan |
06 / Environment variables
Configuration and secrets.
Set them your way
Add variables in the project Environment tab, paste a whole .env file in bulk mode, or use deployxa env set from the terminal.
Masked by default
Secret values are hidden in the dashboard until you reveal or copy them, and they are never written to build logs.
Sync with local files
deployxa env pull writes the project variables to .env.local; deployxa env push uploads them back. env list and env remove do the rest.
Injected, not committed
Variables reach the build and the running container at deploy time, including database credentials Deployxa provisions for you. Change one, then redeploy to apply it.
07 / Monitoring
After the deploy.
Resource and traffic metrics
CPU, memory, requests per hour, average and p95 latency, 5xx error rate and storage, per project and across the organization. Included from the Starter plan, with advanced metrics on Pro and above.
Logs that stay with the release
Build and runtime logs stream live and remain attached to each deployment, so you can compare a good release with a bad one.
Alerts for routing problems
Domains that stop resolving to Deployxa, and failed TLS issuance or renewals, are flagged in the dashboard with a retry action.
Scheduled tasks
Cron jobs run against your project with execution history and logs, so a missed or failing job is visible next to your deploys.
08 / FAQ
Pipeline questions.
How fast is a rollback?
Right after a deploy, the previous release is kept on a warm standby, so rolling back is a traffic switch with no rebuild. Once that window has passed, Deployxa redeploys the earlier release from its cached image, which takes longer but skips the full build.
Which releases can I roll back to?
Any earlier successful deployment in the project history. From the CLI, deployxa rollback accepts latest, previous, production or a specific deployment ID.
What happens if a build or health check fails?
The rollout stops at the failed phase and the current release keeps serving traffic. The deploy log shows which step failed so you can fix it and push again.
Do I need to redeploy after changing an environment variable?
Yes. Changes are saved encrypted and applied on the next deploy, because variables are injected when a release is built and started.
Can I deploy without Git?
Yes. Run deployxa deploy in any project folder and the CLI packages your source, builds it remotely and releases it through the same pipeline.
Ready when you are
Push your first deploy.
Connect a repository and watch the pipeline run.