Deployment Workflows

A deployment workflow is a named, repeatable sequence of operations that RasnuCloud executes on your server on demand. Once defined, you can trigger the same deployment — correctly, every time — from the dashboard, the API, or directly from your CI/CD pipeline.

---

The Problem Workflows Solve

Every team has a deployment process. The problem is that it usually lives in someone's head, a Notion doc, or a shell script that breaks every few months.

With RasnuCloud workflows, your deployment process is:

• Defined once — captured in plain language, version-tracked
• Executed consistently — the same steps, in the same order, every time
• Safe — with a rollback plan built in
• Audited — every run is recorded, with who triggered it and what the result was

---

Creating a Workflow

The fastest way to create a workflow is to perform the deployment once in a conversation, then save it:

Pull the latest code from git, install dependencies, run pending database migrations,
clear the cache, and restart the application workers. Use zero-downtime — don't
restart anything that will interrupt live traffic.

Once it succeeds:

Save this as a deployment workflow called "Production Deploy"

RasnuCloud captures every step and stores it. The next deployment is a single click.

---

Example: Zero-Downtime Release

For production deployments where interruptions aren't acceptable:

Create a zero-downtime deployment workflow:
  1. Pull the new code to a timestamped release directory
  2. Install dependencies in the new directory
  3. Run database migrations
  4. Build production assets
  5. Switch the active release symlink atomically
  6. Reload the application server gracefully — no restart, no dropped connections
  7. Remove releases older than 5 versions to reclaim disk space

---

Triggering a Workflow

From the dashboard: Server page → Deployments → select workflow → Run

From the API:

POST /api/v1/deployments/{workflow-id}/run
Authorization: Bearer <token>

From your CI/CD pipeline (GitHub Actions example):

- name: Deploy via RasnuCloud
  run: |
    curl -s -X POST ${{ secrets.RASNUCLOUD_URL }}/api/v1/deployments/${{ secrets.WORKFLOW_ID }}/run \
      -H "Authorization: Bearer ${{ secrets.RASNUCLOUD_API_TOKEN }}"

Works identically with GitLab CI, Jenkins, CircleCI, Bitbucket Pipelines, and any system that can make an HTTP request.

---

Rollback

If any step fails during a workflow run, RasnuCloud stops execution and gives you three choices:

1. Retry — re-run from the failed step
2. Rollback — execute the rollback steps that were defined when you created the workflow
3. Skip — mark the step as skipped and continue (for non-critical steps)

RasnuCloud never partially applies changes and walks away. Every failed deployment ends in a clean state.

---

Deployment History

Every workflow run is recorded with:

• Start and end time, total duration
• The team member who triggered it (or "API" if triggered programmatically)
• The full output of every step
• Final status — success or failure with the exact error

This history is searchable and permanently available in your Audit Log.

---

Multi-Server Deployments

Run the "Production Deploy" workflow on all three app servers simultaneously

Run "Production Deploy" on each app server one at a time, waiting 2 minutes between
each to confirm the previous one is healthy before continuing

Rolling deployments ensure that if a bad release is deployed to the first server, it's caught before the other two are updated.