Merge branch 'main' into dieri/sqs-triggers-docs

docs/core_concepts/16_roles_and_permissions/index.mdx

@@ -65,6 +65,18 @@ Operators have limited access within a workspace. They can only execute and view
 The recommended way to share scripts and flows with operators is through [auto-generated apps](../6_auto_generated_uis/index.mdx).
 With the second option being of sharing the script and [variables](../2_variables_and_secrets/index.mdx) it depends on (but operators won't be able to load variable directly from the UI/API, only use them within the scripts they have access to).
 
+From the workspace settings, you can configure the operator visibility settings for your workspace. In particular, you can allow/disallow operators to view:
+
+- [Runs](../5_monitor_past_and_future_runs/index.mdx)
+- [Schedules](../1_scheduling/index.mdx)
+- [Resources](../3_resources_and_types/index.mdx)
+- [Variables](../2_variables_and_secrets/index.mdx)
+- [Triggers](../../getting_started/8_triggers/index.mdx)
+- [Audit logs](../14_audit_logs/index.mdx)
+- [Groups](../8_groups_and_folders/index.mdx#groups)
+- [Folders](../8_groups_and_folders/index.mdx#folders)
+- [Workers](../9_worker_groups/index.mdx)
+
 Regarding to [Pricing](/pricing), operators are counted as half of a regular seat ([developers](#developer)) as long as they are operators in all workspaces they are member of.
 
 ### Anonymous app viewers

docs/core_concepts/1_scheduling/index.mdx

@@ -323,7 +323,7 @@ Go the the script or flow's page, click on the `Advanced` button, fill in the da
 
 ![Schedule to run later](./16_schedule_to_run_later.png 'Schedule to run later')
 
-You can see the future runs in the [Runs menu](../../core_concepts/5_monitor_past_and_future_runs/index.mdx), with toggle 'Planned later'.
+You can see the future runs in the [Runs menu](../../core_concepts/5_monitor_past_and_future_runs/index.mdx), with toggle 'Planned later'. You can find the created_at date when the run was scheduled on from the API [get job endpoint](https://app.windmill.dev/openapi.html#tag/job/GET/w/{workspace}/jobs_u/get/{id}) .
 
 <!-- Resources -->
 

docs/core_concepts/40_websocket_triggers/index.mdx

@@ -2,7 +2,7 @@
 
 Windmill can connect to [WebSocket](https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API) servers and trigger runnables (scripts, flows) when a message is received.
 Listening is done from the servers, so it doesn't take up any workers.
-WebSocket triggers are not available on the [Cloud](/pricing).
+WebSocket triggers are not available on the [Cloud](/pricing) Free and Team plans.
 
 ## How to use
 

docs/core_concepts/44_workspace_settings/index.mdx

@@ -4,7 +4,7 @@ Workspace settings are configuration options specific to each workspace and can
 
 Each workspace can be configured through the following sections:
 
-- [Users](../16_roles_and_permissions/index.mdx) - Manage workspace members and their permissions
+- [Users](../16_roles_and_permissions/index.mdx) - Manage workspace members and their permissions, in particular the operator visibility settings
 - [Git Sync](../../advanced/11_git_sync/index.mdx) - Configure Git synchronization for your workspace
 - [Deployment UI](../12_staging_prod/index.md) - Customize the deployment interface
 - [Slack](../../integrations/slack.mdx) - Set up Slack integration and notifications

docs/misc/7_plans_details/index.mdx

@@ -108,21 +108,21 @@ Team plans work at the workspace-level.
 
 The subscription to the Enterprise Self-Host offer is done through a [secure payment link](https://billing.windmill.dev/b/4gw4hu51YbfZ0N200j), with a 1-month free trial. You can reach out to us via [email protected], [Discord](https://discord.com/invite/V7PM2YHsPB), or schedule a [meeting](https://www.windmill.dev/book-demo) for an introduction session.
 
-To have your instance switch from Free Edition to Enterprise Edition, you'll need to change the Windmill image:
+To have your instance switch from Free Edition to Enterprise Edition, make sure to use the [ghcr.io/windmill-labs/windmill-ee](https://github.com/windmill-labs/windmill/pkgs/container/windmill-ee) image in all your servers/workers containers, in particular you'll need to change the Windmill image:
 - [Docker](../../advanced/1_self_host/index.mdx#docker): in [docker-compose.yml](https://raw.githubusercontent.com/windmill-labs/windmill/main/docker-compose.yml) and [.env](https://raw.githubusercontent.com/windmill-labs/windmill/main/.env).
 - [Helm](../../advanced/1_self_host/index.mdx#enterprise-deployment-with-helm): see the [Helm chart repository README](https://github.com/windmill-labs/windmill-helm-charts).
 
-If not done earlier, you can create your first workspace, but your instance will not have access to Enterprise features until the license key is passed.
-
 Upon subscribing, you will receive a [license key](#using-the-license-key-self-host) to pass in the [Instance settings](../../advanced/18_instance_settings/index.mdx#license-key). The key will self-update every day at 2 a.m CET as long as the subscription is valid (being paid). A key is valid for 35 days.
 
+Your license key can be used accross multiple instances. Just make sure to turn dev / staging instances as 'Non-prod' in the [Instance settings](../../advanced/18_instance_settings/index.mdx#non-prod-instance) so that their computation usage is not taken into account.
+
 To adjust the number of seats, you can update your usage on the subscription page at [Windmill customer portal](#windmill-customer-portal).
 
 Windmill employs lightweight [telemetry](#usage-checks) to automatically track and report the usage of memory and seats for your subscription. Even on self-hosted plans, telemetry associated to your license key is reported to Windmill.
 
 How the data is calculated:
 - Seats: number of users (1 developer, or 2 operators) who are active (from logging in to running or deploying a script) on the platform in the last 30 days, according to the [audit logs](../../core_concepts/14_audit_logs/index.mdx). User count is across all instances (dev, prod) but Windmill only counts once the same user.
-- Memory: we aggregate the limits of all production containers. Workers come in different sizes: small (1GB), standard (2GB), and large (> 2GB). For each compute unit, you pay for, you get a quota of 2 worker-gb-month.
+- Memory: we aggregate the limits of all production containers. Workers come in different sizes: small (1GB), standard (2GB), and large (> 2GB). For each [Compute Unit](/pricing#compute-units), you pay for, you get a quota of 2 worker-gb-month.
 
 Using a number of seats, workers, or memory greater than the terms of your subscription is technically possible, but if you do not adjust your subscription accordingly (via the [Customer Portal](#windmill-customer-portal)), we will ask you to take steps to correct this, with 3 options:
 1. Our telemetry data may not be accurate or you do not understand it. In this case, please inform us or book a call: https://www.windmill.dev/ruben-30min
@@ -139,7 +139,7 @@ Once excessive usage has been detected and we have informed you, your license ke
 	/>
 </div>
 
-#### Using the License Key (Self-host)
+#### Using the license key (self-host)
 
 To enable the license key, switch from the `windmill` image to the `windmill-ee` image in both the server and workers. From the [Instance settings](../../advanced/18_instance_settings/index.mdx#license-key), pass the license key, "Test key" and save settings.
 

src/components/Pricing.js

@@ -464,6 +464,17 @@ const sections = [
 				},
 				link: '/docs/advanced/email_triggers'
 			},
+			{
+				name: 'Postgres triggers',
+				tiers: {
+					'tier-free-selfhost': true,
+					'tier-enterprise-selfhost': true,
+					'tier-enterprise-cloud': true,
+					'tier-free': false,
+					'tier-team': false
+				},
+				link: '/docs/core_concepts/postgres_triggers',
+			},
 			{
 				name: 'WebSocket triggers',
 				tiers: {
@@ -474,7 +485,6 @@ const sections = [
 					'tier-team': false
 				},
 				link: '/docs/core_concepts/40_websocket_triggers',
-				tooltip: 'Self-hosted only'
 			},
 			{
 				name: 'Postgres triggers',
@@ -493,24 +503,22 @@ const sections = [
 				tiers: {
 					'tier-free-selfhost': false,
 					'tier-enterprise-selfhost': true,
-					'tier-enterprise-cloud': false,
+					'tier-enterprise-cloud': true,
 					'tier-free': false,
 					'tier-team': false
 				},
 				link: '/docs/core_concepts/kafka_triggers',
-				tooltip: 'Self-hosted only'
 			},
 			{
 				name: 'NATS triggers',
 				tiers: {
 					'tier-free-selfhost': false,
 					'tier-enterprise-selfhost': true,
-					'tier-enterprise-cloud': false,
+					'tier-enterprise-cloud': true,
 					'tier-free': false,
 					'tier-team': false
 				},
 				link: '/docs/core_concepts/nats_triggers',
-				tooltip: 'Self-hosted only'
 			},
 			{
 				name: 'SQS triggers',
@@ -868,12 +876,11 @@ const sections = [
 				tiers: {
 					'tier-free-selfhost': false,
 					'tier-enterprise-selfhost': true,
-					'tier-enterprise-cloud': false,
+					'tier-enterprise-cloud': true,
 					'tier-free': false,
 					'tier-team': false
 				},
 				link: '/docs/core_concepts/critical_alerts',
-				tooltip: 'Self-hosted only'
 			},
 			{
 				name: 'Script-specific workers (dedicated) / High throughput',

src/components/pricing/PricingFAQ.js

@@ -114,7 +114,7 @@ const faqs = [
 		question: 'What are compute units?',
 		answer: (
 			<span>
-				Compute units are a unit of measure for the amount of compute resources used. A compute unit corresponds to 2 worker-gb-month. For example, a <Link
+				Compute units are a unit of measure for the amount of compute resources provisioned for the workers, based on their memory limits. A compute unit corresponds to 2 worker-gb-month. For example, a <Link
 					to="/docs/core_concepts/worker_groups"
 					className="text-blue-600 hover:text-blue-800 dark:text-blue-500 dark:hover:text-blue-600"
 				>
@@ -168,7 +168,7 @@ const faqs = [
 				of one month is meant to help you evaluate your needs in practice.
 				<br />
 				<br />
-				Compute units are based on the provisioned workers, not the scripts. This means your pricing is determined by the size of your infrastructure, not by the memory consumption of individual scripts. Therefore, your costs remain predictable regardless of script demands.
+				Compute units are based on the provisioned workers, not the ones actually used by scripts. This means your pricing is determined by the size of your infrastructure, not by the memory consumption of individual scripts. Therefore, your costs remain predictable regardless of script demands.
 			</span>
 		)
 	},

src/pages/partners.jsx

@@ -36,6 +36,14 @@ const people = [
     email: '[email protected]',
     profile: 'https://www.linkedin.com/in/fitzpatrickstephan/',
     imageUrl: '/images/partners/stphftzptrk.jpg'
+},
+{
+  name: 'David Peter',
+  description: 'David Peter is a TypeScript programmer and founder at Type Driven, a software development agency.',
+  roles: ['Common tree', 'App editor'],
+  email: '[email protected]',
+  profile: 'https://www.linkedin.com/in/david-peter-498423280/',
+  imageUrl: '/images/partners/davidpeter.jpg'
 }
 ];