10 posts tagged with "Workspace"
View All TagsWorkspace forks now get an isolated data environment per DuckLake by default. Materializing pipelines in a fork write to a fork-scoped metadata schema and bucket prefix instead of the parent's tables, and tables the fork has not materialized yet are read from the parent through read-only defer views, so one node can be iterated on without rebuilding upstream. The fork-creation dialog adds a per-lake Isolated / Shared with parent choice, the pipeline graph shows deferred vs fork chips on DuckLake assets, and deleting a fork can drop its forked namespaces.
New features
- Forks default to an isolated data environment per lake: a fork-scoped metadata schema and a __wm_forks/<fork id>/ bucket prefix, with unchanged ducklake:// URIs and annotations
- Read-defer to the parent: tables the fork has not materialized are read through read-only views over the parent data, including the <table>_current companion view of SCD2 targets
- Parent lakes are attached read-only in forks, so a fork job cannot write parent data through DuckLake
- Fork-creation dialog gains a Ducklake data environment section with a per-lake Isolated (default) or Shared with parent choice; shared forks read and write the parent lake directly
- Pipeline graph marks each DuckLake asset in a fork with an amber deferred or emerald fork chip, with a matching banner in the details pane
- Fork deletion offers to drop forked DuckLake namespaces; also available as POST /w/<workspace>/workspaces/drop_forked_ducklake_namespaces
10GiB workspace storage quota replaces 50MB upload cap on Community Edition
S3Persistent storageWorkspacev1.746.0The Community Edition 50MB per-file upload cap on workspace object storage is replaced by a 10GiB total storage quota per workspace. Files of any individual size can be uploaded up to the quota, usage is shown in the workspace settings under S3 Storage with a recount button, and reads and deletes are never blocked even when over quota. Enterprise Edition remains unlimited.
New features
- Upload files of any individual size to workspace object storage on Community Edition, up to 10GiB of total workspace storage.
- Storage usage meter in workspace settings under S3 Storage, with a button to recount usage by listing the storage.
- Writes exceeding the quota are rejected, but reads and deletes are never blocked, so an over-quota workspace can always free up space.
- The quota counts all objects under the configured storages except the reserved volumes/ prefix; Enterprise Edition remains unlimited.
Workspace forks are now available on app.windmill.dev for workspaces on a paid plan. A fork inherits its parent (root) workspace's premium status and usage limits, and its executions are metered into the parent's billing. Free-tier workspaces cannot fork, and the number of forks is capped at 5 per paid developer seat of the root workspace.
New features
- Fork workspaces on Windmill Cloud for paid (Team or Enterprise) workspaces.
- Forks inherit the parent (root) workspace plan and usage limits.
- Fork executions are metered into the parent workspace billing.
- Fork count capped at 5 per paid developer seat of the root workspace.
- Free-tier workspaces cannot create forks on cloud.
Pair a persistent dev workspace with a prod workspace that can be locked so changes only reach it through promotion. Edit safely in dev, mark resources and variables workspace-specific to keep separate values per environment, and promote manually from Compare & Deploy.
New features
- Persistent dev workspace with a plain, git-branch-safe workspace ID (no wm-fork- prefix)
- Lock the paired prod workspace against direct deploys and forking (reuses protection rulesets)
- On a locked prod, Edit redirects to the dev workspace with an "Edit in <dev>" affordance
- Attach or detach an existing workspace as dev from the Dev workspace settings tab
- Mark resources and variables workspace-specific from Compare & Deploy to keep separate values per environment
- Strictly create-only "Create in <other>" seeds a missing copy (including secrets) without overwriting
- AI chat session picker badges and steers toward the dev workspace on a locked prod
Workspace forks now include data tables, and the new wmill workspace merge command enables merging forks back to the parent.
New features
- Data tables are included when forking a workspace.
- New wmill workspace merge CLI command.
- Color support in forked workspaces.
Attach free-form labels to scripts, flows, apps, resources, variables, schedules, and triggers for organization and filtering.
New features
- Labels on all workspace item types.
- Labels propagate to jobs at runtime for traceability.
- Filter jobs by labels in the runs page.
Create workspace-scoped automation identities that cannot log in directly, for CI/CD pipelines and API integrations.
New features
- Workspace-scoped service accounts that cannot log in.
- Always operators with a username-only identity.
- Admin impersonation for testing permissions.
Trashbin for soft-deleting items
WorkspaceDeleted items are now moved to a trashbin with a 3-day retention window, allowing admins to restore accidentally deleted scripts, flows, apps, and other workspace items.
New features
- Deleted items are soft-deleted to a trashbin instead of permanently removed.
- Restore any trashed item from workspace settings within 3 days.
- Supports scripts, flows, apps, schedules, variables, resources, and all trigger types.
- Admins can permanently delete individual items or empty the entire trashbin.
- Automatic expiration after 3 days.
Email error handlers are now available for workspace and trigger error handling. Send automated error notifications via email when jobs fail, supporting multiple recipients and integration with existing error handling workflows.
New features
- Email error handlers for workspace-level error notifications
- Support for multiple email recipients with validation
- Available for both workspace and trigger-specific error handling
- Integration with existing Slack, Teams, and custom error handlers
- Self-hosted instances only (requires SMTP configuration)
Trigger error handlers now allow you to configure specific error handling for individual triggers. Override workspace error handlers with custom, Slack, Teams, or email notifications per trigger.
New features
- Configure error handlers for individual triggers (HTTP routes, Webhooks, Kafka, SQS, WebSocket, Postgres, NATS, MQTT, GCP, Email)
- Override workspace error handlers with trigger-specific handling
- Support for custom scripts, Slack, Teams, and email error handlers
- Additional arguments and retry configuration for custom error handlers
- Works with scripts only (not flows)