Changelog

App header is now a component default for all apps, that can be moved, modified or deleted.

We've made our runtime that we've called "REST" and "nativets" support npm packages and relative imports! There is now no difference in the syntax of TypeScript/Bun scripts and native scripts. Native scripts still only support a subset of what node supports (just the fetch operation) but many npm packages can still be used because that's all they use under the hood (for instance, windmill-client and axios).

How to activate? Just add //native to the head of your script. Windmill will automatically convert between 'nativets' and 'Bun' scripts based on the presence of this header so you can always just pick TypeScript (Bun) and decide at the end if you want to accelerate it with 'native' if possible.

We've also changed the default docker-compose/helm template to go from 4 small native workers with each 1 subworker to 1 bigger native worker with 8 subworkers as it performed better in our benchmarks. If you need more throughput, simply increase the replicas of the native workers, don't increase the number of subworkers past 8 as the interleaving will result in lower throughput.

This is a huge improvement as you can now make our native runtime an implementation details and we can unify everything under the standard "TypeScript" language without anything Windmill-specific. Legacy native/fetch scripts will still work but the new REST button now simply prefill a Bun script with a //native header.

Native runtime is great for scripts that are doing simple fetch and require little compute but are io-bound on the response from the API. You can get parallelization of 8 requests/scripts at a time with a single worker, resulting in 8x better throughput between Bun and native scripts at scale.

Windmill now pre-bundles TypeScript (Bun) scripts using Bun bundler and caches them on S3 and locally at deployment time. Furthermore, if a Bun script is run while not being pre-bundled, it will be re-bundled. This will increase stability and optimize (in some cases with 60% improvement) the execution time and the memory consumption, in particular for scripts with many/heavy imports and relative imports.

We also did improvements for non-deployed scripts using better caching strategies for the dependency cache. You cannot do any faster than running a pre-bundled script aside from having the script being already running which is what dedicated workers are made for. This makes Windmill the fastest platform to run TypeScript.

However, in very rare cases (< 1%), this might break existing bun scripts that are incompatible with being bundled. If you notice such issue for a particular script after the upgrade, add //nobundling to the top of the script.

Dynamic Select is an helper function within scripts that allows you to create a select field with dynamic options.

Improved the flow status viewer readability.

The Navbar component facilitates control over an app by changing its ctx.query and jumping into another app.

Flows now have versions just like scripts and apps.

Added new type of input `oneOf@, that displays an option between multiple objects.

Windmill now automatically tracks relative imports in Bun and Python such that if you update a common dependency and update its imports, it will now re-trigger deployment and lockfile computation of all the scripts that depend on it (it was working for Python but not Bun before).

Windmill can now also track such imports in inline scripts of flows and will surgically update the inline lockfiles of those flows if the relative imports change.

We have released our new Windmill Billing Portal https://portal.windmill.dev/.

You can access your Portal from your Instance Settings, in the "Core" tab. Or by visiting https://portal.windmill.dev/, entering your email and then accessing the link sent via email. Update contact information, billing details and subscription (seats & vCPUs) from the portal. From there, you can also enable/disable any time automatic renewal and automatic debit (therefore payment by invoice).

In the Usage section, you can find the Seats of vCPUs usage of your Prod instance, and check whether your use of Windmill corresponds to your subscription. There is a ‘Report an error’ button, please use it if reported usage is incorrect.

It's also an opportunity for us to explain our new way of managing license keys for self-hosted instances.

As you know, when you subscribe to Windmill, you receive a license key to enter in the instance settings. Now, this key automatically updates every day as long as the subscription is valid. A key is valid for 35 days and expires as soon as an updated key replaces it. This system relieves you from having to worry about your key expiring. Now everything is automatic as long as your subscription is valid. You can still contact us for exceptions.

With all Windmill S3 Integration features, read and write from a storage that is not your main storage by specifying it in the s3 object as "secondary_storage" with the name of it.

Windmill AI has been upgrading from GPT 4 and GPT-3.5-turbo to GPT-4o

Apps are executed on behalf of publishers and by default cannot access viewer's resources.

If the resource passed here as a reference does not come from a static Resource Select component (which will be whitelisted by the auto-generated policy), you need to toggle "Resources from users allowed".

The toggle "Static resource select only / Resources from users allowed" can be found for each runnable input when the source is an eval.

Obversability around concurrent jobs has been improved from the Runs menu.

When set to full height, a component (in its respective view type, desktop or mobile) components will have their height go down until the end of the parent container (if no, canvas).

PHP is now supported as a primary language along TypeScript, Python, Go, Bash, or SQL languages.

Rest scripts are in fact TypeScript fetches. They support all the normal signatures of normal TypeScript but only stdlib JavaScript and the fetch operations. Imports are not allowed. But now the full wmill API is supported.

You can visualize metrics for Delayed jobs per tag and Queue delay per tag.

Latest CLI and Git Sync have 2 major improvements:

1. Wherever there is a lockfile (in scripts, flows and apps), the lockfile is now stored in a separate file (<same_path_as_script_or_inline_script>.lock) and referenced in the yaml by !inline <path of lock>. We had numerous feedback from EE customers that the lockfile were hard to diff and added lots of boilerplate to otherwise clean yaml files.

2. Script in apps (even frontend scripts) are now stored in separate files, similar to what is the case for flows. Which mean now apps are their own folders:myapp.yaml -> myapp.app/app.yaml + myapp.app/inline_script1.ts + myapp.app/inline_script1.lock + ...

This will improve greatly the ability to use commits/PR to review scripts, flows and apps changes.

To do a clean update:
- Upgrade Deno.
- Upgrade wmill CLI to latest.
- Do a wmill sync pull and push to your repo.
-update the CLI used to 1.320.3 in your GitHub actions.
- Update your git sync script (we've made that easier, just click button and save git settings).

The AgGrid Infinite Table component allows you to display an Ag Grid table with infinite scrolling.

Labels allow to add static or dynamic tags to jobs with property "wm_labels" followed by an array of strings (e.g. return {"wm_labels":["showcase_labels", "another_label"]}

AgGrid and Database Studio rows now support actions, components that will be displayed at each row of the table.

When enabled, the flow will continue to the next step after going through all the retries (if any) even if this step fails.

While loops execute a sequence of code indefinitely until the user cancels or a step set to Early Stop stops.

Improved the experience with approval steps.

Map support in Rich Display Rendering.

We now support GH flavored markdown for description of scripts, flows, resources.

You can set and retrieve a value given a key from any step of flow and it will be available from within the flow globally.

From Variables tab, admins can create custom contextual variables that will act as env variables for all jobs within a workspace.

One of our large scale customers noticed that their database disk usage was much much higher than they anticipated. After investigation, we realized that our use of the database for streaming was very suboptimal in a few ways due to the nature of update in postgres. When you update a row in Postgres, it will actually keep the prior row as a dead tuple until it is collected. It doesn't matter in much case but it will if you're appending a few log lines to a 25MB log row, every 500ms.

We have completely refactored the way we deal with logs in major ways and starting on 1.295.0 you should feel comfortable having extremely large logs on Windmill

First action we took was to extract the logs from the queue table to a separate table. That was to avoid update unrelated to logs creating dead tuples. Second action was to make the streaming rate from the worker adaptive to the duration of the job, a longer job does not need to update its log every 500ms, every 2.5s is reasonable for jobs of more than 10s, 5s for 60s+, etc...

But that was still not enough, even every 2.5s an update on a 25mb log would create lots of heavy dead tuples. And 25MB is not that large, our customer should feel confident streaming GBs of logs per job with jobs that run for months.

So we completely revisited the way we store logs to only treat the database as a buffer for streaming purpose rather than long term storage. We keep the db as a 5000 char buffer to still provide the same instant preview as before but

1. On EE, the logs will be streamed to S3 if you connected your instance to S3, everything is seamless and you can still download the entire log, Windmill will take care of streaming from S3

2. non EE, the excess log (>10000 chars) will be stored on disk of the worker (mount /tmp/windmill/logs to persist those).

Now the db only stores at most 5Kb of logs per job rows, reducing the pressure on it by order of magnitudes, while users can now run jobs with unlimited logs with minimal impact on the worker or db. And the logs are still as live as before

On self-hosted instances, workspaces can have names and IDs updated from the workspace settings.

Windmill supports many languages, but organizations usually only use a few, now you can configure the languages that are visible and their order.

Flows are not the only way to write distributed programs that execute distinct jobs. Another approach is to write a program that defines the jobs and their dependencies, and then execute that program. This is known as workflows as code.

Pin database resource path directly within a SQL script instead of filling it through the UI.

The Flow & Metadata Copilot is an assistant powered by an OpenAI resource that simplifies your script & flows building experience by population fields (summaries, descriptions, step input expressions) automatically based on context and prompts.

All secrets of a workspace are encrypted with a symmetric key unique to that workspace. This key is generated when the workspace is created and is stored in the database in the workspace_settings. You can now manually update the encryption key of a workspace, it will be re-encrypted with the new key and the previous key will be replaced by the new one.

If configured, users who are operators in this workspace will be redirected to this app automatically when logging into this workspace.

Introducing the Database Studio, a web-based database management tool that leverages Ag Grid for table display and interaction. In apps, interaction with database content made easy; from a SQL resource, display, edit, add rows, delete rows ... and connect to other components.

Added rich results render for arrays of objects and markdown in scripts and flows.

Windmill provides a true NodeJS compatibility mode using Bun. This means that you can run your existing NodeJS code without any modifications. Only comment //nodejs on the first line of your Bun script.

The Ag Charts component integrates the Ag Charts library, enabling the visualization of data through various chart types. This component is designed to offer a flexible and powerful way to display data graphically within the application.

This app component allows you to create a decision tree controlled by a flow-like structure. Each node in the tree represents a decision point with a dedicated subgrid and can lead to one or more subsequent nodes based on specified conditions.