Deploy history and build log retention

Every time you deploy — by pushing to your branch or using Manual Deploy — Voroa records it. The Deploys tab for your service shows this history, and each deploy has its own page with the full build log, so you can always go back and see what happened on a specific deploy.

View your recent deploys

Open your service and go to the Deploys tab. You will see your most recent deploys, newest first, with:

• The commit message and short commit hash for the deploy.
• The Status — for example Live, Building, Starting, Failed, or Build failed. See Deploy status for what each one means.
• The Trigger — whether the deploy came from a push to GitHub or a manual deploy.
• The Duration — how long the deploy took.

You can search your deploys by commit message or hash, and filter by status, to quickly find the one you are looking for.

Open a single deploy

Click any deploy in the list to open its own page. The deploy page shows, at a glance:

• Status — the live status of that deploy. While a deploy is in progress this updates on its own, moving from Building to Starting to Live (or to Failed if something goes wrong).
• Source — the commit that was deployed.
• Trigger — how the deploy was started.
• Duration — the total time the deploy took.

Below that is the full build log for the deploy. If the deploy is still running, the log streams live as the build progresses. Once the deploy finishes, the log stays available so you can review exactly what the build did.

The stages of a deploy

Above the build log is a timeline showing which stage the deploy is in and how long each one took. A deploy moves through these stages in order:

• Queued — the deploy is recorded and waiting to start.
• Cloning — Voroa fetches your repository at the commit being deployed.
• Building — your dependencies are installed and your build command runs. This is usually the longest stage.
• Preparing image — your built application is packaged, ready to run.
• Running pre-deploy command — only if you have set one, for example a database migration. It runs on the same machine and private network as your service, inside the newly built version, before it goes live. If it fails or runs past the build time limit, nothing is replaced, and any version already running keeps serving.
• Deploying — the new copy of your service is started. For most services it starts alongside the copy already running, so there is no gap. A service with a persistent disk is the exception: a disk can only be attached to one copy at a time, so the old copy is stopped first and there is a short gap while the new one starts.
• Health check — Voroa waits for your new copy to answer before sending traffic to it. If your service is slow to start, this is the stage where that shows.
• Live — the new copy is serving, and the old one has been removed.

Stages that do not apply to your service are not shown. A static site has no Building stage because there is nothing to build; a rollback has no Cloning or Building stage because it reuses a version you already deployed; and a service with no pre-deploy command does not show that stage. Only the stages that actually ran appear, each with its real duration.

If a deploy fails, the stage it failed in is marked, so you can tell a build failure apart from a service that built correctly but did not start. Your previous version keeps serving unless the deploy got far enough to replace it, and the log says which happened.

Reading the build log

The log is grouped by stage, matching the timeline. Finished stages start collapsed so the screen opens on what matters; the stage still running, and any stage that hit an error, are open already. A collapsed stage tells you how many errors are inside it, so nothing is hidden behind a closed group.

• Search filters the whole log and opens every stage, so a match is never trapped inside a collapsed one.
• Errors and Warnings counts at the top are buttons - click one to see only those lines. The stage headings stay visible so you can still tell where each line came from.
• Download log saves what you are currently looking at as a text file.
• Copy logs copies the same thing to your clipboard.

If a deploy fails, a notice above the log names the stage that failed and shows the first error, with a link that jumps to it in place - so you can see what ran just before it.

Lines are colour-coded: errors in red, warnings in amber, the stage markers in blue. The colour only changes how a line looks, never whether it is shown.

What the log contains

Everything your own build commands write — your installer, your bundler, your test runner — appears in the log as they wrote it. Voroa’s own setup steps, which run before yours to prepare the image, are left out: they are the same on every build and say nothing about your code.

A build where every layer came from cache is the one case with little to show. Nothing of yours ran, so there is nothing of yours to print, and the stage timings above the log are the honest record of what happened.

When a deploy finishes, the stage with the most output opens on its own so you land on what you came to read. A very large stage - a few thousand lines or more - stays closed instead, with its line count on the header, so the page opens quickly; click it when you want it. Download log and Copy logs always give you the whole thing either way.

How long build logs stay visible

Voroa shows build logs for as many days as your plan allows (see the table below). This keeps your dashboard fast, and it matches how most cloud platforms handle logs.

After the retention window:

• The deploy still appears in your history, with its status, commit, trigger, and duration intact — nothing is removed from the list.
• Its build log is no longer available. Opening an older deploy shows a clear message that the log is past the retention window, instead of an empty screen.

If you want a permanent record of a build, copy the log while the deploy is recent, or trigger a fresh deploy to generate a new build you can review.

How far back you can see logs

How many days of runtime and build logs you can see depends on your workspace plan:

The Logs tab has three controls above the log:

• Search logs finds lines that contain your text, in upper or lower case. It searches the whole time range you picked (the last 24 hours in Live tail), not only the lines on screen. It matches the text your service wrote, so a phrase that your service coloured in two parts may not be found as one phrase.
• The level menu shows All levels, only Errors, or only Warnings. It looks for words such as error, fatal, exception or warning in each line, so it works best when your service writes the level into its log lines.
• The time range menu picks what you see. Live tail shows the newest lines and refreshes every few seconds. Last hour through Last 30 days show the newest 1,000 lines of that range, and Custom lets you pick a start and end. Ranges longer than your plan allows are shown but cannot be picked.
• Load older adds the lines printed just before the oldest one on screen. Press it again to keep going back, as far as your plan allows. While you look at a range or older lines, the view stops refreshing; pick Live tail to return to the newest.

The same ranges are available through the API by passing start and end (milliseconds since 1970) on the runtime logs request, and q to search. One request can cover your plan’s whole window; a range older than your plan allows returns a clear message naming your plan’s number of days. From the command line, voroa logs <service> --search TEXT does the same search over the last 24 hours. Longer windows fill in from the day they were introduced, so days before that may be empty.

Times on runtime log lines

Every runtime log line shows the time your service printed it, in your browser’s local time, in the column to the left of the line, and the date appears above the first line of each day. Next to the time, a short tag in square brackets such as [tnb0bv] names the running copy that wrote the line; it changes when a new deploy goes live, so you can see where the old version stopped and the new one started. The time comes from Voroa, not from your log text, so it is there even when your service prints plain lines with no timestamp of its own.

When the runtime log view is empty

Runtime logs are whatever your service prints while it runs, so there are two ordinary reasons the view is blank, and neither is a fault:

• The service has never deployed. Until a deploy runs, there is no running service to print anything. Deploy it once and the log view fills as it starts.
• The service is running quietly. A service that has printed nothing since it started has nothing to show. Add a log line at startup if you want to confirm it is alive.

An empty log view is not an error message, and Voroa will not show one in its place. If the logs genuinely cannot be read right now, you get a clear “temporarily unavailable” notice instead, and retrying a moment later is the right thing to do.

Cancel a deploy that is in progress

While a deploy is building, Cancel deploy sits next to Manual Deploy on Overview, on the Deploys list, and on that deploy’s own page (the page with the live build log). Cancelling drops a deploy that is still waiting in the queue, or stops one that is already building. Your currently running version is never touched - it keeps serving traffic exactly as it was. The cancelled deploy appears in your history so the record stays honest.

Roll back to the previous version

Manual Deploy > Rollback to previous version brings back the version that was serving before your latest deploy - without rebuilding anything, so it completes in seconds. The switch is checked before it happens: if the previous version cannot start for any reason, your current version simply keeps serving.

Two things to know:

• Rollback needs at least one earlier deploy on the current infrastructure - on a service’s very first deploy there is nothing to roll back to yet.
• Rollback restores the previous code. Your current environment variables, secret files and domains stay as they are.

Next steps

• Deploy status: Live, Starting, Failed, and Build failed
• Deploy a web app from GitHub
• Automatic deploys on every push
• Rollbacks: putting the previous version back