Add Activepieces integration for workflow automation
- Add Activepieces fork with SmoothSchedule custom piece - Create integrations app with Activepieces service layer - Add embed token endpoint for iframe integration - Create Automations page with embedded workflow builder - Add sidebar visibility fix for embed mode - Add list inactive customers endpoint to Public API - Include SmoothSchedule triggers: event created/updated/cancelled - Include SmoothSchedule actions: create/update/cancel events, list resources/services/customers 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
This commit is contained in:
poduck
48
activepieces-fork/docs/install/guides/separate-workers.mdx
Normal file
48
activepieces-fork/docs/install/guides/separate-workers.mdx
Normal file
@@ -0,0 +1,48 @@
|
||||
---
|
||||
title: 'How to Separate Workers'
|
||||
description: ''
|
||||
icon: 'robot'
|
||||
---
|
||||
|
||||
Benefits of separating workers from the main application (APP):
|
||||
|
||||
- **Availability**: The application remains lightweight, allowing workers to be scaled independently.
|
||||
- **Security**: Workers lack direct access to Redis and the database, minimizing impact in case of a security breach.
|
||||
|
||||
|
||||
<Steps>
|
||||
<Step title="Create Worker Token">
|
||||
To create a worker token, use the local CLI command to generate the JWT and sign it with your `AP_JWT_SECRET` used for the app server. Follow these steps:
|
||||
1. Open your terminal and navigate to the root of the repository.
|
||||
2. Run the command: `npm run workers token`.
|
||||
3. When prompted, enter the JWT secret (this should be the same as the `AP_JWT_SECRET` used for the app server).
|
||||
4. The generated token will be displayed in your terminal, copy it and use it in the next step.
|
||||
|
||||
</Step>
|
||||
<Step title="Configure Environment Variables">
|
||||
Define the following environment variables in the `.env` file on the worker machine:
|
||||
- Set `AP_CONTAINER_TYPE` to `WORKER`
|
||||
- Specify `AP_FRONTEND_URL`
|
||||
- Provide `AP_WORKER_TOKEN`
|
||||
</Step>
|
||||
<Step title="Configure Persistent Volume">
|
||||
Configure a persistent volume for the worker to cache flows and pieces. This is important as first uncached execution of pieces and flows are very slow. Having a persistent volume significantly improves execution speed.
|
||||
|
||||
Add the following volume mapping to your docker configuration:
|
||||
```yaml
|
||||
volumes:
|
||||
- <your path>:/usr/src/app/cache
|
||||
```
|
||||
Note: This setup works whether you attach one volume per worker, It cannot be shared across multiple workers.
|
||||
</Step>
|
||||
<Step title="Launch Worker Machine">
|
||||
Launch the worker machine and supply it with the generated token.
|
||||
</Step>
|
||||
<Step title="Verify Worker Operation">
|
||||
Verify that the workers are visible in the Platform Admin Console under Infra -> Workers.
|
||||
|
||||
</Step>
|
||||
<Step title="Configure App Container Type">
|
||||
On the APP machine, set `AP_CONTAINER_TYPE` to `APP`.
|
||||
</Step>
|
||||
</Steps>
|
||||
33
activepieces-fork/docs/install/guides/setup-app-webhooks.mdx
Normal file
33
activepieces-fork/docs/install/guides/setup-app-webhooks.mdx
Normal file
@@ -0,0 +1,33 @@
|
||||
---
|
||||
title: "How to Setup App Webhooks"
|
||||
description: ""
|
||||
icon: 'webhook'
|
||||
---
|
||||
|
||||
Certain apps like Slack and Square only support one webhook per OAuth2 app. This means that manual configuration is required in their developer portal, and it cannot be automated.
|
||||
|
||||
## Slack
|
||||
|
||||
**Configure Webhook Secret**
|
||||
|
||||
1. Visit the "Basic Information" section of your Slack OAuth settings.
|
||||
2. Copy the "Signing Secret" and save it.
|
||||
3. Set the following environment variable in your activepieces environment:
|
||||
```
|
||||
AP_APP_WEBHOOK_SECRETS={"@activepieces/piece-slack": {"webhookSecret": "SIGNING_SECRET"}}
|
||||
```
|
||||
4. Restart your application instance.
|
||||
|
||||
|
||||
**Configure Webhook URL**
|
||||
|
||||
1. Go to the "Event Subscription" settings in the Slack OAuth2 developer platform.
|
||||
2. The URL format should be: `https://YOUR_AP_INSTANCE/api/v1/app-events/slack`.
|
||||
3. When connecting to Slack, use your OAuth2 credentials or update the OAuth2 app details from the admin console (in platform plans).
|
||||
4. Add the following events to the app:
|
||||
- `message.channels`
|
||||
- `reaction_added`
|
||||
- `message.im`
|
||||
- `message.groups`
|
||||
- `message.mpim`
|
||||
- `app_mention`
|
||||
@@ -0,0 +1,19 @@
|
||||
---
|
||||
title: "How to Setup OpenTelemetry"
|
||||
description: "Configure OpenTelemetry for observability and tracing"
|
||||
icon: "chart-line"
|
||||
---
|
||||
|
||||
Activepieces supports both standard OpenTelemetry environment variables and vendor-specific configuration for observability and tracing.
|
||||
|
||||
## Environment Variables
|
||||
|
||||
| Variable | Description | Default Value | Example |
|
||||
|----------|-------------|---------------|---------|
|
||||
| `AP_OTEL_ENABLED` | Enable OpenTelemetry tracing | `false` | `true` |
|
||||
| `OTEL_EXPORTER_OTLP_ENDPOINT` | OTLP exporter endpoint URL | None | `https://your-collector:4317/v1/traces` |
|
||||
| `OTEL_EXPORTER_OTLP_HEADERS` | Headers for OTLP exporter (comma-separated key=value pairs) | None | `Authorization=Bearer token` |
|
||||
|
||||
<Note>
|
||||
Both `AP_OTEL_ENABLED` and `OTEL_EXPORTER_OTLP_ENDPOINT` must be set for OpenTelemetry to be enabled.
|
||||
</Note>
|
||||
27
activepieces-fork/docs/install/guides/setup-s3.mdx
Normal file
27
activepieces-fork/docs/install/guides/setup-s3.mdx
Normal file
@@ -0,0 +1,27 @@
|
||||
---
|
||||
title: "How to Setup S3"
|
||||
description: "Configure S3-compatible storage for files and run logs"
|
||||
icon: "cloud"
|
||||
---
|
||||
|
||||
Run logs and files are stored in the database by default, but you can switch to S3 later without any migration; for most cases, the database is enough.
|
||||
|
||||
It's recommended to start with the database and switch to S3 if needed. After switching, expired files in the database will be deleted, and everything will be stored in S3. No manual migration is needed.
|
||||
|
||||
## Environment Variables
|
||||
|
||||
| Variable | Description | Default Value | Example |
|
||||
|----------|-------------|---------------|---------|
|
||||
| `AP_FILE_STORAGE_LOCATION` | The location to store files. Set to `S3` for S3 storage. | `DB` | `S3` |
|
||||
| `AP_S3_ACCESS_KEY_ID` | The access key ID for your S3-compatible storage service. Not required if `AP_S3_USE_IRSA` is `true`. | None | |
|
||||
| `AP_S3_SECRET_ACCESS_KEY` | The secret access key for your S3-compatible storage service. Not required if `AP_S3_USE_IRSA` is `true`. | None | |
|
||||
| `AP_S3_BUCKET` | The name of the S3 bucket to use for file storage. | None | |
|
||||
| `AP_S3_ENDPOINT` | The endpoint URL for your S3-compatible storage service. Not required if `AWS_ENDPOINT_URL` is set. | None | `https://s3.amazonaws.com` |
|
||||
| `AP_S3_REGION` | The region where your S3 bucket is located. Not required if `AWS_REGION` is set. | None | `us-east-1` |
|
||||
| `AP_S3_USE_SIGNED_URLS` | It is used to route traffic to S3 directly. It should be enabled if the S3 bucket is public. | None | `true` |
|
||||
| `AP_S3_USE_IRSA` | Use IAM Role for Service Accounts (IRSA) to connect to S3. When `true`, `AP_S3_ACCESS_KEY_ID` and `AP_S3_SECRET_ACCESS_KEY` are not required. | None | `true` |
|
||||
| `AP_MAX_FILE_SIZE_MB` | The maximum allowed file size in megabytes for uploads including logs of flow runs. | `10` | `10` |
|
||||
|
||||
<Tip>
|
||||
**Friendly Tip #1**: If the S3 bucket supports signed URLs but needs to be accessible over a public network, you can set `AP_S3_USE_SIGNED_URLS` to `true` to route traffic directly to S3 and reduce heavy traffic on your API server.
|
||||
</Tip>
|
||||
73
activepieces-fork/docs/install/guides/setup-ssl.mdx
Normal file
73
activepieces-fork/docs/install/guides/setup-ssl.mdx
Normal file
@@ -0,0 +1,73 @@
|
||||
---
|
||||
title: "Setup HTTPS"
|
||||
description: ""
|
||||
icon: "shield"
|
||||
---
|
||||
|
||||
To enable SSL, you can use a reverse proxy. In this case, we will use Nginx as the reverse proxy.
|
||||
|
||||
## Install Nginx
|
||||
|
||||
```bash
|
||||
sudo apt-get install nginx
|
||||
```
|
||||
|
||||
|
||||
## Create Certificate
|
||||
|
||||
To proceed with this documentation, it is assumed that you already have a certificate for your domain.
|
||||
|
||||
<Tip>
|
||||
You have the option to use Cloudflare or generate a certificate using Let's Encrypt or Certbot.
|
||||
</Tip>
|
||||
|
||||
|
||||
Add the certificate to the following paths: `/etc/key.pem` and `/etc/cert.pem`
|
||||
|
||||
|
||||
## Setup Nginx
|
||||
|
||||
```bash
|
||||
sudo nano /etc/nginx/sites-available/default
|
||||
```
|
||||
|
||||
|
||||
```bash
|
||||
server {
|
||||
listen 80;
|
||||
listen [::]:80;
|
||||
|
||||
server_name example.com www.example.com;
|
||||
|
||||
return 301 https://$server_name$request_uri;
|
||||
}
|
||||
|
||||
server {
|
||||
listen 443 ssl http2;
|
||||
listen [::]:443 ssl http2;
|
||||
|
||||
server_name example.com www.example.com;
|
||||
|
||||
ssl_certificate /etc/cert.pem;
|
||||
ssl_certificate_key /etc/key.pem;
|
||||
|
||||
location / {
|
||||
proxy_pass http://localhost:8080;
|
||||
proxy_http_version 1.1;
|
||||
proxy_set_header Upgrade $http_upgrade;
|
||||
proxy_set_header Connection 'upgrade';
|
||||
proxy_set_header Host $host;
|
||||
proxy_cache_bypass $http_upgrade;
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## Restart Nginx
|
||||
|
||||
```bash
|
||||
sudo systemctl restart nginx
|
||||
```
|
||||
|
||||
## Test
|
||||
|
||||
Visit your domain and you should see your application running with SSL.
|
||||
Reference in New Issue
Block a user