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

docs/core_concepts/43_preprocessors/index.mdx

@@ -23,7 +23,7 @@ Here are examples of a preprocessor function in [TypeScript](../../getting_start
 export async function preprocessor(
 	/* args from the request body (e.g. webhook/http body args, msg for ws/kafka/nats, raw_email and parsed_email for email) */ 
 	wm_trigger: {
-		kind: 'http' | 'email' | 'webhook' | 'websocket' | 'kafka' | 'nats',
+		kind: 'http' | 'email' | 'webhook' | 'websocket' | 'postgres' | 'kafka' | 'nats', 'sqs',
 		http?: {
 			route: string // The route path, e.g. "/users/:id"
 			path: string // The actual path called, e.g. "/users/123"
@@ -49,7 +49,14 @@ export async function preprocessor(
 			length: number
 		},
 		sqs?: {
-			queue_url: string
+			queue_url: string,
+			message_id?: string,
+			receipt_handle?: string,
+			attributes: Record<string, string>,
+			message_attributes?: Record<string, {
+				string_value?: string,
+				data_type: string
+			}>
 		}
 	}
 ) {
@@ -92,11 +99,19 @@ class Nats(TypedDict):
 	description: str | None
 	length: int
 
-class Sqs(TypedDict):
-	queue_url: str
+class MessageAttribute(TypedDict):
+   string_value: str | None
+   data_type: str
+
+class Sqs(TypeDict):
+   queue_url: str
+   message_id: str | None
+   receipt_handle: str | None
+   attributes: dict[str, str]
+   message_attributes: dict[str, MessageAttribute] | None
 
 class WmTrigger(TypedDict):
-	kind: Literal["http", "email", "webhook", "websocket", "kafka", "nats", "sqs"]
+	kind: Literal["http", "email", "webhook", "websocket", "postgres", "kafka", "nats", "sqs"]
 	http: Http | None
 	websocket: Websocket | None
 	kakfa: Kafka | None
@@ -136,7 +151,7 @@ The flow preprocessor takes the same arguments as the script preprocessor and sh
 export async function preprocessor(
 	/* args from the request body (e.g. webhook/http body args, msg for ws/kafka/nats/sqs, raw_email and parsed_email for email) */ 
 	wm_trigger: {
-		kind: 'http' | 'email' | 'webhook' | 'websocket' | 'kafka' | 'nats',
+		kind: 'http' | 'email' | 'webhook' | 'websocket' | 'postgres' | 'kafka' | 'nats', 'sqs',
 		http?: {
 			route: string // The route path, e.g. "/users/:id"
 			path: string // The actual path called, e.g. "/users/123"
@@ -158,7 +173,14 @@ export async function preprocessor(
 			subject: string
 		},
 		sqs?: {
-			queue_url: string
+			queue_url: string,
+			message_id?: string,
+			receipt_handle?: string,
+			attributes: Record<string, string>,
+			message_attributes?: Record<string, {
+				string_value?: string,
+				data_type: string
+			}>
 		}
 	}
 ) {
@@ -197,11 +219,19 @@ class Nats(TypedDict):
 	description: str | None
 	length: int
 
-class Sqs(TypedDict):
-	queue_url: str
+class MessageAttribute(TypedDict):
+   string_value: str | None
+   data_type: str
+
+class Sqs(TypeDict):
+   queue_url: str
+   message_id: str | None
+   receipt_handle: str | None
+   attributes: dict[str, str]
+   message_attributes: dict[str, MessageAttribute] | None
 
 class WmTrigger(TypedDict):
-    kind: Literal["http", "email", "webhook", "websocket", "kafka", "nats", "sqs"]
+    kind: Literal["http", "email", "webhook", "websocket", "postgres", "kafka", "nats", "sqs"]
     http: Http | None
 	websocket: Websocket | None
 	kafka: Kafka | None

docs/core_concepts/46_postgres_triggers/index.mdx

@@ -18,7 +18,7 @@ Postgres triggers are not available on the [Cloud](/pricing).
 
 Windmill's Postgres trigger feature is built on Postgres's logical replication protocol, which allows changes to a database to be streamed in real time to subscribers. Logical replication provides fine-grained control over what data is replicated by allowing the user to define publications and subscribe to specific changes.
 
-#### How logical replication works:
+### How logical replication works
 1. **Publications**: Define what changes (e.g., INSERT, UPDATE, DELETE) should be made available for replication. Publications allow you to select specific tables or schemas to track.
 2. **Replication slots**: Ensure that all changes from a publication are retained until they are successfully delivered to the subscriber (e.g., Windmill triggers). This guarantees data reliability and prevents data loss.
 
@@ -27,8 +27,96 @@ Windmill uses logical replication to efficiently stream database changes to your
 For more details, see the [Postgres documentation on logical replication](https://www.postgresql.org/docs/current/logical-replication.html).  
 For more details, see the [Postgres documentation on logical replication streaming protocol](https://www.postgresql.org/docs/current/protocol-logical-replication.html).
 
+
+## Requirements
+
+Before using Postgres triggers with Windmill, your database must be properly configured for logical replication. The primary requirement is setting the Write-Ahead Log (WAL) level to `'logical'`.
+
+### Setting `wal_level` to `logical`
+
+You have two options to configure this setting. Both options require a restart of your Postgres instance to take effect.
+
+#### Option 1: Using SQL (requires database restart)
+
+1. Run the following SQL command to set `wal_level` to `'logical'`:         
+
+  ```sql
+   ALTER SYSTEM SET wal_level = 'logical';
+  ```
+
+2. After executing the command, restart your Postgres instance for the changes to take effect.
+
+#### Option 2: Editing the `postgresql.conf` file (requires database restart)
+
+1. Locate and open your `postgresql.conf` file. The location of this file may vary depending on your installation.
+
+2. Look for the `wal_level` setting. If it's not already present, **add** the following line to the file:
+
+  ```ini
+   wal_level = logical
+  ```
+
+   If the setting is already there, **update** it to `logical`.
+
+3. Save the file and restart your Postgres instance for the changes to take effect.
+
+### Verifying Logical Replication
+
+You can verify that logical replication is enabled by running the following query:
+
+```sql
+SHOW wal_level;
+```
+
+This should return:
+
+```plaintext
+ wal_level
+-----------
+ logical
+```
+
+### Impact of Enabling Logical Replication
+
+Enabling logical replication turns on detailed logging, which is essential for supporting the replication process. Be aware that this will increase the amount of data written to the Write-Ahead Log (WAL). Typically, you can expect a 10% to 30% increase in the amount of data written to the WAL, depending on the volume of write activity in your database.
+
+---
+
+## Additional Configuration for Logical Replication
+
+For logical replication to work properly, you need to configure additional parameters in your `postgresql.conf` file. These parameters control the number of replication processes and slots available for replication. Both settings require a restart of your Postgres instance to take effect.
+
+#### `max_wal_senders`
+
+The `max_wal_senders` setting determines the maximum number of **walsender** processes that can run concurrently. A **walsender** is responsible for sending the Write-Ahead Log (WAL) data to subscribers for logical replication. The default value is 10, but you can increase this based on your replication needs.
+
+```ini
+#max_wal_senders = 10  # max number of walsender processes (change requires restart)
+```
+
+- **Impact on Triggers**: Each active trigger in logical replication will use a **walsender** process. So, if `max_wal_senders` is set to 10, only 10 active triggers can be used at the same time. If you reach this limit, you will need to increase the `max_wal_senders` value to accommodate more active triggers.
+
+#### `max_replication_slots`
+
+The `max_replication_slots` setting determines how many **replication slots** can be created. Replication slots are used to maintain state for each logical replication subscription. This setting also limits the number of triggers that can be created for logical replication.
+
+```ini
+#max_replication_slots = 10  # max number of replication slots (change requires restart)
+```
+
+- **Impact on Trigger Creation**: You can only create as many triggers as there are replication slots available. So if `max_replication_slots` is set to 10, you will be able to create a maximum of 10 triggers. If you need more triggers, you will need to increase the `max_replication_slots` value.
+
+### Summary of Limits
+
+- **Active triggers**: The number of active triggers you can have is limited by `max_wal_senders`. If you set `max_wal_senders` to 10, only 10 active triggers can be running simultaneously.
+
+- **Trigger creation**: The number of triggers you can create is limited by `max_replication_slots`. If you set `max_replication_slots` to 10, you can only create 10 triggers in total.
+
 ---
 
+### Final Considerations
+
+When configuring these settings, make sure to account for the number of active triggers and replication slots needed for your application. If you expect to have many triggers or high replication activity, you may need to increase both `max_wal_senders` and `max_replication_slots`.
 ## How to use
 Learn how to set up and configure Postgres triggers in Windmill through these key steps.
 

docs/getting_started/8_triggers/index.mdx

@@ -272,7 +272,7 @@ Windmill can connect to WebSocket servers and trigger runnables (scripts, flows)
 
 ### Postgres triggers
 
-Windmill can connect to postgres database servers and trigger runnables (scripts, flows) when a message is received.
+Windmill can connect to a [Postgres](https://www.postgresql.org/) database and trigger runnables (scripts, flows) in response to database transactions (INSERT, UPDATE, DELETE) on specified tables, schemas, or the entire database.  
 
 <div className="grid grid-cols-2 gap-6 mb-4">
 	<DocCard

docs/misc/14_saml_and_scim/index.md

@@ -16,6 +16,12 @@ Application username format is `Email`
 
 In the Instance settings UI, pass the SAML Metadata URL (or content) containing the metadata URL (or XML content).
 
+:::tip
+
+You can control the entity ID using the `SAML_AUDIENCE` environment variable. This can be useful if you want to use the same identity provider for multiple instances (e.g dev / prod).
+
+:::
+
 ### Okta
 
 Configure Okta with the following settings (and replace cf.wimill.xyz with your domain):

docs/script_editor/settings.mdx

@@ -244,6 +244,18 @@ Windmill can connect to WebSocket servers and trigger runnables (scripts, flows)
 	/>
 </div>
 
+### Postgres
+
+Windmill can connect to a [Postgres](https://www.postgresql.org/) database and trigger runnables (scripts, flows) in response to database transactions (INSERT, UPDATE, DELETE) on specified tables, schemas, or the entire database.  
+
+<div className="grid grid-cols-2 gap-6 mb-4">
+	<DocCard
+		title="Postgres triggers"
+		description="Trigger scripts and flows from postgres database servers."
+		href="/docs/core_concepts/postgres_triggers"
+	/>
+</div>
+
 ### Kafka
 
 Windmill can connect to Kafka brokers and trigger scripts or flows when messages are received on specific topics. This enables real-time processing of events from your Kafka ecosystem.

src/components/Pricing.js

@@ -469,13 +469,25 @@ const sections = [
 				tiers: {
 					'tier-free-selfhost': true,
 					'tier-enterprise-selfhost': true,
-					'tier-enterprise-cloud': false,
+					'tier-enterprise-cloud': true,
 					'tier-free': false,
 					'tier-team': false
 				},
 				link: '/docs/core_concepts/40_websocket_triggers',
 				tooltip: 'Self-hosted only'
 			},
+			{
+				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/46_postgres_triggers',
+				tooltip: 'Self-hosted only'
+			},
 			{
 				name: 'Kafka triggers',
 				tiers: {