Unable to install on a managed database
I'm getting lots of errors when running windmill for the first time. I have added all the details here https://github.com/windmill-labs/windmill/issues/9560.
**New draft system** Windmill now automatically saves your changes while editing. Drafts are now user-scoped: different users can work on their own version of a script/flow/app without interference. You can see and load other users' drafts, which allows simple collaborative workflows. For more complex collaborative use cases, we recommend using workspace forks (Enterprise Edition): https://windmill.dev/docs/advanced/workspace_forks Read more: https://windmill.dev/docs/core_concepts/draft_and_deploy
Diego · 2mo ago
**Docker runtime v2** We've implemented a completely new runtime for docker support. Instead of acting as an awkward docker client to an external deamon, your job now run your image using our existing sandboxing and chrooting technology around nsjail. It's much simpler, much more efficient, much safer (using an external dind leave many holes open) while leveraging your existing worker resources. Just head your bash script with: ``` # sandbox my-image your commands ``` The #docker annotation is still possible and work as before for back-compatibility, but is now considered legacy. And because it's properly sandboxed it works in our multitenant app.windmill.dev cloud.
rubenf · 2mo ago
We lost the habit of putting everything here but we still have many great features that have been merged recently and a few very big ones coming soon. ⚠️ ⚠️ semi-breaking change in Postgres TIMESTAMP return However, want to take the opportunity to warn about a semi breaking change in the way our native Postgres runtime return TIMESTAMP . it used to be in this format: "2026-05-08 17:54:03.348891 UTC" . but they are have been standardized to (ISO 8601): "2026-05-08T17:54:03.348891+00:00" in recent releases. If you relied critically on the specific format, be advised you will need to adapt to this change. It was mistakenly in the UTC format prior which is non standard, not consistent with pg behavior and not even consistent with what format taken as input by our pg runtime as valid TIMESTAMP. Sorry about this, we realized a bit late that by doing a batch of runtime improvement on pg, it induced this change and it's now too late to revert or make fully back-compatible.
rubenf · 3mo ago
Join the Discord to ask follow-up questions and connect with the community
W
