Sevalla Changelog #0107 Ingot, Cron History, and a Better Web Terminal
Ingot builds, cron run history, exact-commit deploys, API and CLI updates, web terminal upgrades, and security fixes.
Establishing connection…
Signal detected.
Link established.
Baud here with a 56k Sevalla changelog transmission.
Eight updates shipped over the last two weeks. This round gives production teams more control over how applications build, deploy, run, and fail, without handing them another layer of infrastructure to operate.
Ingot gives Sevalla builds a production-first default#
New applications and preview apps deployed from Git now build with Ingot, Sevalla’s own builder.
Ingot detects your language, framework, language version, and package manager, then writes the production Dockerfile and builds the application. It uses official language images, respects your lock file, runs as a non-root user, and produces the same Dockerfile for the same commit.
That last part matters.
Build systems should make deployments more predictable, not introduce another source of mystery. With Ingot, the generated Dockerfile is part of the deployment history, so you can see exactly what Sevalla built and compare changes between deployments.
Ingot supports Node.js, Bun, Deno, Python, PHP, Ruby, Go, Rust, Java, .NET, Elixir, Gleam, Zig, C and C++, static sites, and shell scripts. If automatic detection is not what you need, override it with ingot.json or INGOT_* environment variables.
Existing applications keep their current build strategy until you change it. To move one, open Settings, select Update build strategy, and choose Ingot.
Nixpacks is now deprecated, but existing Nixpacks applications continue to work.
Applications built with Ingot or their own Dockerfile also get Dockerfile history. Every Dockerfile used to build the application is retained, including which one is currently running and what changed between any two versions. Each deployment now has a Dockerfile tab, and the same information is available through the API.
Cron jobs finally have a memory#
A cron job that fails at 3:00 a.m. should not leave you reconstructing what happened from scattered logs the next morning.
Sevalla now records every cron run for 30 days, whether it was scheduled or started manually with Run now.
The cron card on the Processes tab shows the latest 30 runs and reflects the status of the most recent one: Running, Succeeded, or Failed.
Open Run history to inspect when each run was due, how long it took, how many times it retried, and why it failed. Failure reasons include the exit code, maximum run time, or the run being replaced by the next scheduled execution.
Click the run time to go directly to its logs.
The same history is available through the List cron runs API operation.
Less guesswork. Faster answers when scheduled production work stops behaving.
Preview environments no longer require the dashboard#
Preview apps are useful. Preview apps that can only be configured manually are harder to standardize.
You can now create and configure pipeline preview apps through the API and CLI.
The API lets you define the preview app’s location, build configuration, hibernation behavior, processes, disks, TCP proxies, and environment variables. You can then create a preview app directly for a branch or pull request and start its first deployment.
Persistent disks also have dedicated API operations for listing disk resource types, attaching or updating a process disk, and detaching one.
The CLI exposes matching commands.
That means preview environments and persistent storage can now be part of your normal automation instead of an extra dashboard step.
For teams managing multiple repositories or standardized deployment workflows, that is the point: infrastructure should fit the workflow, not interrupt it.
Preview apps through the API and CLI
Deploy the commit you actually want#
A branch points to the latest commit. Production does not always need the latest commit.
The Manual deploy flow for Git applications now includes a Commit field. Paste a full commit SHA, or a GitHub, GitLab, or Bitbucket commit URL, and Sevalla will build that exact commit using the application’s current settings and environment variables.
Need to find the SHA? Browse commits opens the branch history in your Git provider.
Leave the field empty and manual deploy continues to use the latest commit, just as before.
The API supports the same workflow through commit_sha in the Trigger deployment operation.
This gives teams a cleaner path for reproducing a known deployment, testing a specific revision, or moving production back to known-good code without manipulating the branch first.
The web terminal now behaves like a real terminal#
A production terminal should not disappear because your laptop went to sleep.
We rebuilt the Sevalla web terminal around that principle.
Terminal sessions now survive connection drops for 15 minutes. Change networks, reload the page, or wake your laptop and the terminal reconnects automatically, including the output you missed. If the application image includes tmux, Start in tmux can keep the shell alive even if the terminal service itself restarts.
You can open up to eight tabs per application and split them into panes. Each tab can connect to any web process or background worker with sh, bash, or zsh, and your browser remembers the layout.
File transfer is built in too. Drop files or folders into a terminal pane to upload them, or download files and folders up to 100 MB from the Files menu.
Full-screen applications now get a properly sized terminal, with TERM=xterm-256color and a UTF-8 locale. That means tools such as tmux and vim behave the way you expect.
Keyboard shortcuts adapt to macOS, Windows, and Linux. Settings cover font size, theme, cursor, scrollback, and more. Terminal bell events can trigger tab indicators and desktop notifications, useful when an agent such as Claude Code is waiting for approval.
There is also connection status, round-trip information, reconnect details, and a mobile key bar for Esc, Tab, Ctrl, Alt, and arrow keys.
This is still a browser terminal. It just stops feeling like a compromise.
Node.js patched for Nixpacks applications#
The October 21 Node.js security release fixed CVE-2026-111497 and nine other vulnerabilities.
Nixpacks builds on Sevalla now install patched Node.js versions 22.23.4 and 24.22.1. This includes the Node.js runtime that Nixpacks adds to PHP and Ruby applications.
CVE-2026-111497 is an out-of-bounds write in the Brotli decoder that can allow remote code execution.
When a repository does not specify a Node.js version, Nixpacks now installs Node.js 22 instead of Node.js 18.
Node.js 18 and 20 are end of life and do not receive this fix. Applications that explicitly pin one of those versions will continue using it, so update the version to Node.js 22 or 24 through engines.node in package.json or NIXPACKS_NODE_VERSION.
To update a running application, redeploy the latest deployment with Skip build cache selected.
This change applies to Nixpacks only. Railpack, Buildpacks, and Dockerfile builds manage Node.js independently.
PHP applications need attention too#
PHP released versions 8.5.12, 8.4.27, 8.3.36, and 8.2.35 to address two critical vulnerabilities: CVE-2026-109618 and CVE-2026-109619.
Both vulnerabilities can allow an attacker to execute code on a server using a crafted HTTP request.
Applications running older affected PHP versions need action regardless of whether they use Nixpacks, Railpack, Buildpacks, or a Dockerfile.
We published a dedicated advisory with two paths.
The first is a quick mitigation using three PHP settings that requires one deployment and no application code changes. The advisory provides steps for each supported build strategy.
The second is upgrading to the appropriate patched PHP release.
Security fixes are not the place for vague advice. Check your PHP version and patch affected applications.
Support is one click away#
Support is now available directly from the dashboard’s top bar.
Click Support from any page to open support chat. Unread replies appear directly on the button, and narrow screens use a chat icon instead.
Chat with support remains available from the Help menu.
For company owners and admins, the setting that controls Stella’s access to the account has also been renamed AI support settings, making its purpose clearer.
A small change, but when something is affecting production, fewer clicks are better.
Transmission complete#
Changelog #0107 makes production work easier to inspect, automate, reproduce, secure, and operate without pushing more infrastructure onto your team.
More improvements on the way.
Awaiting next transmission.
Link closed.