diff --git a/apps/sim/lib/compare/data/competitors/claude-cowork.ts b/apps/sim/lib/compare/data/competitors/claude-cowork.ts index 520bf5550d4..7a063e55c78 100644 --- a/apps/sim/lib/compare/data/competitors/claude-cowork.ts +++ b/apps/sim/lib/compare/data/competitors/claude-cowork.ts @@ -647,10 +647,10 @@ export const claudeCoworkProfile: CompetitorProfile = { }, codeSandboxRuntime: { value: - 'Partial: shell commands and any code Claude writes run in an isolated sandbox (a dedicated Linux VM for local sessions, a per-session temporary sandbox on Anthropic-managed infrastructure for cloud sessions), and within a session Claude can itself install dependencies at run time from approved package managers (npm/registry.npmjs.org, PyPI/files.pythonhosted.org, GitHub, crates.io, Yarn). What an administrator configures is the org-wide network-egress policy rather than the environment: Team and Enterprise organization owners choose, in Organization settings > Capabilities, between network access off (Claude "operates with pre-installed packages only"), package managers only, package managers plus an admin-specified domain allowlist, or all domains except Anthropic\'s legal blocklist.', + 'Yes: at the package layer only, and driven by the agent rather than a declared environment. Shell commands and any code Claude writes run in an isolated sandbox (a dedicated Linux VM for local sessions, a per-session temporary sandbox on Anthropic-managed infrastructure for cloud sessions), and within a session Claude can itself install dependencies at run time from approved package managers (npm/registry.npmjs.org, PyPI/files.pythonhosted.org, GitHub, crates.io, Yarn). What an administrator configures is the org-wide network-egress policy rather than the environment: Team and Enterprise organization owners choose, in Organization settings > Capabilities, between network access off (Claude "operates with pre-installed packages only"), package managers only, package managers plus an admin-specified domain allowlist, or all domains except Anthropic\'s legal blocklist.', detail: 'The configuration surface is an org-wide network-egress policy plus run-time installs the agent performs itself, not a declared environment: there is no manifest of packages, no OS/system-package list, no preinstalled-CLI selection, and no custom base image or Dockerfile for the sandbox, and Anthropic does not publish the preinstalled package set for Cowork sandboxes. Network settings apply when a session is created, so changing them mid-conversation requires starting a new one.', - shortValue: 'Partial: agent installs packages at run time; environment not declarable', + shortValue: 'Yes: agent installs packages at run time; environment not declarable', confidence: 'verified', sources: [ { @@ -928,10 +928,10 @@ export const claudeCoworkProfile: CompetitorProfile = { }, sessionPolicy: { value: - 'Partial: the setting is available only to "Admins and Owners of Enterprise plans and Console Admins," who can enable a shortened session length of 1, 7, 14, or 28 days (Console Admins get 1, 3, or 7 days), after which "users will need to sign in again after the specified period, even if they\'ve been actively using Claude." This is an absolute lifetime cap from sign-in, not an inactivity timeout, and no idle timeout is documented.', + 'Yes: on Enterprise plans only. The setting is available only to "Admins and Owners of Enterprise plans and Console Admins," who can enable a shortened session length of 1, 7, 14, or 28 days (Console Admins get 1, 3, or 7 days), after which "users will need to sign in again after the specified period, even if they\'ve been actively using Claude." This is an absolute lifetime cap from sign-in, not an inactivity timeout, and no idle timeout is documented.', detail: "Because the control is Enterprise/Console-gated, administrators on other plans cannot set a session lifetime at all; with the setting disabled, sessions return to the default behavior of remaining active as long as the user stays active, with no documented idle timeout. Because one session spans all of a user's organizations, the shortest configured duration across them applies. Disabling the setting does not retroactively extend sessions already scheduled to expire.", - shortValue: 'Partial: Enterprise/Console only, 1/7/14/28-day absolute cap', + shortValue: 'Yes: Enterprise/Console only, 1/7/14/28-day absolute cap', confidence: 'verified', sources: [ { diff --git a/apps/sim/lib/compare/data/competitors/crewai.ts b/apps/sim/lib/compare/data/competitors/crewai.ts index 811898524c2..bb728ab8244 100644 --- a/apps/sim/lib/compare/data/competitors/crewai.ts +++ b/apps/sim/lib/compare/data/competitors/crewai.ts @@ -656,10 +656,10 @@ export const crewaiProfile: CompetitorProfile = { }, codeSandboxRuntime: { value: - 'Partial: CrewAI no longer ships a sandbox of its own. The Docker-backed CodeInterpreterTool was removed from crewai-tools in April 2026 and the docs now direct users to a third-party sandbox service, so the execution environment is configured in that provider. What remains first-party is AMP deployment: a deployed crew installs whatever the project declares in pyproject.toml/uv.lock, including private-registry packages.', + 'Yes: at the package layer on CrewAI AMP, where a deployed crew installs whatever the project declares in pyproject.toml/uv.lock, including private-registry packages. There is no first-party sandbox to configure: the Docker-backed CodeInterpreterTool was removed from crewai-tools in April 2026 and the docs now direct users to a third-party sandbox service, so image and resource configuration happen in that provider instead.', detail: "The CodeInterpreterTool page now carries a deprecation warning stating that the tool 'has been removed from crewai-tools' and that the allow_code_execution and code_execution_mode parameters on Agent are also deprecated, directing users to a dedicated sandbox service (E2B or Modal) instead; CERT/CC VU#221883 records the same vendor statement, that the tool including its Docker sandbox and its restricted-Python fallback was removed in response to code-execution vulnerabilities. In its place crewai-tools ships wrappers for third-party sandboxes (e2b_sandbox_tool, daytona_sandbox_tool), so image, package, and resource configuration follow that provider's model and account rather than CrewAI's. Separately, a crew deployed to CrewAI AMP is built from the repository's own pyproject.toml with a required uv.lock, so the deployed runtime contains the packages the developer declared, including packages from a private registry configured through [[tool.uv.index]] plus UV_INDEX_*_USERNAME/PASSWORD environment variables. Outside AMP, CrewAI is a Python library with no sandbox of its own: crew code runs in whatever interpreter and virtualenv the developer starts it in, so the dependency set is fully theirs to control and equally unisolated.", - shortValue: 'Partial, AMP deploy dependencies; code sandbox delegated to E2B/Daytona', + shortValue: 'Yes, AMP deploy dependencies only; code sandbox delegated to E2B/Daytona', confidence: 'verified', sources: [ { @@ -937,7 +937,7 @@ export const crewaiProfile: CompetitorProfile = { }, sessionPolicy: { value: - "Not publicly documented: no admin-configurable session lifetime or idle timeout appears in CrewAI AMP's public docs; the SSO, RBAC, and self-hosted configuration pages name no session control", + 'No: no admin-configurable session lifetime or idle timeout is documented for CrewAI AMP on any deployment mode; the SSO, RBAC, and self-hosted Helm configuration pages name no session control, and CrewAI does not document where session length is set. The identity providers it lists (WorkOS, Microsoft Entra ID, Okta, Auth0, Keycloak) are third-party, so any timeout configured there comes from the IdP rather than from CrewAI. The open-source framework has no user accounts or sign-in at all.', detail: "CrewAI's platform SSO page documents WorkOS (the SaaS default), Microsoft Entra ID, Okta, Auth0, and Keycloak as identity providers and delegates MFA enforcement to the IdP, but names no session-lifetime, absolute-cap, or inactivity-timeout setting; the RBAC permission matrix likewise covers default_settings and organization_settings without a session control. The self-hosted Helm chart's WorkOS variables (WORKOS_CLIENT_ID, WORKOS_AUTHKIT_DOMAIN, WORKOS_COOKIE_PASSWORD, WORKOS_API_KEY) document credentials and cookie encryption but no lifetime or expiry setting. CrewAI does not document where session length is controlled, and no session-duration behavior is stated either way. The open-source framework has no user accounts or sign-in at all, so the question does not apply to it.", shortValue: 'No documented session-lifetime or idle-timeout setting', diff --git a/apps/sim/lib/compare/data/competitors/dust.ts b/apps/sim/lib/compare/data/competitors/dust.ts index 5ebf1328fe4..35b44ff09b8 100644 --- a/apps/sim/lib/compare/data/competitors/dust.ts +++ b/apps/sim/lib/compare/data/competitors/dust.ts @@ -928,7 +928,7 @@ export const dustProfile: CompetitorProfile = { }, sessionPolicy: { value: - 'Not publicly documented: Dust documents SAML SSO with workspace-wide enforcement and SCIM provisioning on the Enterprise plan, but no admin-configurable absolute session lifetime or idle timeout, and no fixed session length is published either', + 'No: no admin-configurable absolute session lifetime or idle timeout is documented anywhere, and no fixed session length is published either. Dust documents SAML SSO with workspace-wide enforcement and SCIM provisioning on the Enterprise plan, but enforcing SSO governs which login methods are accepted rather than how long a signed-in session lasts, so session length in practice follows whatever the upstream third-party identity provider enforces at re-authentication, which is not a Dust-owned policy', detail: "Dust's workspace governance docs describe the admin surface under Admin > People & Security as managing security settings, user access, identity verification, and provisioning; neither those pages nor the SSO/SAML pages describe a session-duration, idle-timeout, or forced re-authentication setting. Enforcing SSO restricts which login methods are accepted (users can no longer sign in with social accounts) rather than how long a signed-in session lasts, so session length in practice follows whatever the upstream identity provider enforces at re-authentication.", shortValue: 'No documented session-lifetime or idle-timeout setting', diff --git a/apps/sim/lib/compare/data/competitors/flowise.ts b/apps/sim/lib/compare/data/competitors/flowise.ts index eda221873d5..388bebf22f2 100644 --- a/apps/sim/lib/compare/data/competitors/flowise.ts +++ b/apps/sim/lib/compare/data/competitors/flowise.ts @@ -536,10 +536,10 @@ export const flowiseProfile: CompetitorProfile = { }, codeSandboxRuntime: { value: - 'Partial: self-hosted only and at the image level. The runtime available to Custom JS Function and Custom Tool code is controlled by server environment variables: TOOL_FUNCTION_BUILTIN_DEP (which NodeJS built-in modules code may require, set to crypto,fs in the shipped .env.example and documented as accepting * for all builtins), TOOL_FUNCTION_EXTERNAL_DEP (which npm packages are importable, set to moment,lodash,pg,mysql2,mongodb,ioredis,redis,typeorm,@zilliz/milvus2-sdk-node in the same file), and ALLOW_BUILTIN_DEP, which the docs describe as allowing the project dependencies already bundled with Flowise to be used, illustrated with cheerio and typeorm. Adding an npm package that is not already bundled requires adding it to packages/components, rebuilding Flowise, and restarting the server, so it is a redeploy of your own image rather than a per-step dependency declaration; there is no runtime npm install inside the code node, and no documented way to declare OS-level system packages or preinstalled CLI binaries. Flowise does not document any way for users of the managed Flowise Cloud product to set these server environment variables.', + 'Yes: on self-hosted deployments only, and at the image level. The runtime available to Custom JS Function and Custom Tool code is controlled by server environment variables: TOOL_FUNCTION_BUILTIN_DEP (which NodeJS built-in modules code may require, set to crypto,fs in the shipped .env.example and documented as accepting * for all builtins), TOOL_FUNCTION_EXTERNAL_DEP (which npm packages are importable, set to moment,lodash,pg,mysql2,mongodb,ioredis,redis,typeorm,@zilliz/milvus2-sdk-node in the same file), and ALLOW_BUILTIN_DEP, which the docs describe as allowing the project dependencies already bundled with Flowise to be used, illustrated with cheerio and typeorm. Adding an npm package that is not already bundled requires adding it to packages/components, rebuilding Flowise, and restarting the server, so it is a redeploy of your own image rather than a per-step dependency declaration; there is no runtime npm install inside the code node, and no documented way to declare OS-level system packages or preinstalled CLI binaries. Flowise does not document any way for users of the managed Flowise Cloud product to set these server environment variables.', detail: 'The Custom Tool docs describe the workflow explicitly: add the package under packages/components with pnpm add, run pnpm build, "then, add the imported libraries to TOOL_FUNCTION_EXTERNAL_DEP environment variable", then restart the application. TOOL_FUNCTION_BUILTIN_DEP is additive rather than a replacement: packages/components/src/utils.ts concatenates it onto a hardcoded defaultAllowBuiltInDep list (assert, buffer, crypto, events, path, querystring, timers, url, zlib), so the shipped crypto,fs value widens that base set rather than defining it; TOOL_FUNCTION_EXTERNAL_DEP is additive in the same way, layered onto a defaultAllowExternalDependencies list of axios and node-fetch. Python is not a supported code-step runtime at all, so the configurable surface is Node-only.', - shortValue: 'Self-hosted only: env-var allowlists plus a rebuild; no Cloud control', + shortValue: 'Yes, self-hosted only: env-var allowlists plus a rebuild; no Cloud control', confidence: 'verified', sources: [ { @@ -789,10 +789,11 @@ export const flowiseProfile: CompetitorProfile = { }, sessionPolicy: { value: - 'Partial: self-hosted server environment variables rather than an admin-console setting. JWT_TOKEN_EXPIRY_IN_MINUTES sets the access-token lifetime and JWT_REFRESH_TOKEN_EXPIRY_IN_MINUTES sets the refresh-token lifetime, which together bound how long a sign-in survives, and EXPIRE_AUTH_TOKENS_ON_RESTART invalidates all tokens on server restart. No idle/inactivity timeout is documented, and Flowise does not document any equivalent control for admins of the managed Flowise Cloud product.', + 'Yes: on self-hosted deployments only, through server environment variables rather than an admin-console setting. JWT_TOKEN_EXPIRY_IN_MINUTES sets the access-token lifetime and JWT_REFRESH_TOKEN_EXPIRY_IN_MINUTES sets the refresh-token lifetime, which together bound how long a sign-in survives, and EXPIRE_AUTH_TOKENS_ON_RESTART invalidates all tokens on server restart. No idle/inactivity timeout is documented, and Flowise does not document any equivalent control for admins of the managed Flowise Cloud product.', detail: 'The shipped .env.example sets JWT_TOKEN_EXPIRY_IN_MINUTES=360 and JWT_REFRESH_TOKEN_EXPIRY_IN_MINUTES=43200 (30 days); the Application authorization docs page instead cites defaults of 60 minutes and 129,600 minutes (90 days), so the documented default differs from the shipped one. Because these are process environment variables, changing them is a deploy-level action for the whole instance, not a per-organization policy an account admin can set from the Workspaces UI.', - shortValue: 'Self-hosted JWT expiry env vars; no idle timeout, no documented Cloud control', + shortValue: + 'Yes, self-hosted JWT expiry env vars; no idle timeout, no documented Cloud control', confidence: 'verified', sources: [ { diff --git a/apps/sim/lib/compare/data/competitors/gumloop.ts b/apps/sim/lib/compare/data/competitors/gumloop.ts index 936f979c68f..d934bcb8856 100644 --- a/apps/sim/lib/compare/data/competitors/gumloop.ts +++ b/apps/sim/lib/compare/data/competitors/gumloop.ts @@ -980,10 +980,10 @@ export const gumloopProfile: CompetitorProfile = { }, sessionPolicy: { value: - 'Not publicly documented: no admin-configurable session lifetime or idle timeout appears in Gumloop\'s public documentation. The only primary-source statement is a single bullet on the Enterprise SSO page listing "Session Management: Configurable session timeouts and secure token handling." No admin setting name, configuration steps, default session lifetime, idle-timeout value, or absolute-cap value is published anywhere in Gumloop\'s docs, security page, or trust center.', + 'No: no admin-configurable session lifetime or idle timeout appears in Gumloop\'s public documentation. The only primary-source statement is a single bullet on the Enterprise SSO page listing "Session Management: Configurable session timeouts and secure token handling." No admin setting name, configuration steps, default session lifetime, idle-timeout value, or absolute-cap value is published anywhere in Gumloop\'s docs, security page, or trust center, so a buyer has no documented control to rely on.', detail: "The bullet sits in a Security & Compliance list introduced as \"Gumloop's SSO implementation follows industry security standards\", alongside SOC 2 Type II certification, SAML 2.0 and TLS 1.3 entries that are compliance assurances rather than admin-configurable settings, so it does not establish a customer-facing control. The same page documents its actual admin controls in detail, including per-direction SCIM mapping-table toggles, name-based mapping mode, and named audit events, but describes no session setting; it gates SAML and SCIM settings to the Admin organization role and an Enterprise subscription, so any such control would be Enterprise-tier. Gumloop's public security page and trust center make no mention of session lifetime, idle timeout, or forced re-authentication. Because SAML SSO is available, organizations can also inherit re-authentication frequency from their upstream IdP, but that is the IdP's policy rather than a Gumloop-enforced one.", - shortValue: 'Single SSO-page bullet cites configurable timeouts; no setting documented', + shortValue: 'No: no documented session lifetime or idle-timeout setting', confidence: 'estimated', sources: [ { diff --git a/apps/sim/lib/compare/data/competitors/langchain.ts b/apps/sim/lib/compare/data/competitors/langchain.ts index 7c5b3e90b19..f5182962ea5 100644 --- a/apps/sim/lib/compare/data/competitors/langchain.ts +++ b/apps/sim/lib/compare/data/competitors/langchain.ts @@ -935,10 +935,10 @@ export const langchainProfile: CompetitorProfile = { }, sessionPolicy: { value: - 'Partial: self-hosted LangSmith only. An operator sets the maximum session length via the OAUTH_SESSION_MAX_SEC environment variable when using OAuth 2.0/SSO, or BASIC_AUTH_JWT_EXPIRATION_SECONDS when using basic authentication, both defaulting to 28800 seconds (8 hours). No equivalent admin-configurable session control is documented for LangSmith Cloud.', + 'Yes: on self-hosted LangSmith deployments only, where an operator sets the maximum session length via the OAUTH_SESSION_MAX_SEC environment variable when using OAuth 2.0/SSO, or BASIC_AUTH_JWT_EXPIRATION_SECONDS when using basic authentication, both defaulting to 28800 seconds (8 hours). No equivalent admin-configurable session control is documented for LangSmith Cloud.', detail: 'Both settings are an absolute cap on session lifetime from sign-in; no separate inactivity/idle timeout is documented. On the cloud product, LangChain support states that after a SAML assertion is validated the session token (a JWT) is issued by LangSmith\'s own auth layer rather than the IdP, and that this "is by design and is not configurable", so an upstream IdP session policy does not govern the resulting LangSmith session either.', - shortValue: 'Self-hosted env vars (8h default); not configurable on cloud', + shortValue: 'Yes, self-hosted env vars (8h default); not configurable on cloud', confidence: 'verified', sources: [ { diff --git a/apps/sim/lib/compare/data/competitors/langflow.ts b/apps/sim/lib/compare/data/competitors/langflow.ts index c481c2f9548..c806e83eafc 100644 --- a/apps/sim/lib/compare/data/competitors/langflow.ts +++ b/apps/sim/lib/compare/data/competitors/langflow.ts @@ -562,10 +562,10 @@ export const langflowProfile: CompetitorProfile = { }, codeSandboxRuntime: { value: - 'Partial: on self-hosted deployments only, the Python environment custom components run in is user-configurable. Langflow Desktop reads a `requirements.txt` in its data directory (`~/.langflow/data/requirements.txt` on macOS) where dependencies are pinned as `DEPENDENCY==VERSION`; Langflow OSS accepts `uv add DEPENDENCY` in a cloned repo and optional dependency groups via pip extras such as `langflow[postgresql]`; and a custom Docker image built on `langflowai/langflow:latest` can layer a `pyproject.toml` plus `uv.lock` for extra packages and mount custom component folders via `LANGFLOW_COMPONENTS_PATH`. Extension packages are pip-installable and register their bundles into the component palette when the server starts. No equivalent dependency configuration is documented for the managed Langflow Cloud.', + 'Yes: on self-hosted deployments only, the Python environment custom components run in is user-configurable. Langflow Desktop reads a `requirements.txt` in its data directory (`~/.langflow/data/requirements.txt` on macOS) where dependencies are pinned as `DEPENDENCY==VERSION`; Langflow OSS accepts `uv add DEPENDENCY` in a cloned repo and optional dependency groups via pip extras such as `langflow[postgresql]`; and a custom Docker image built on `langflowai/langflow:latest` can layer a `pyproject.toml` plus `uv.lock` for extra packages and mount custom component folders via `LANGFLOW_COMPONENTS_PATH`. Extension packages are pip-installable and register their bundles into the component palette when the server starts. No equivalent dependency configuration is documented for the managed Langflow Cloud.', detail: "This is environment configuration at the deployment level, not a per-step sandbox: packages are declared for the whole Langflow server and applied on restart, and there is no documented per-flow or per-component isolation boundary. Langflow's own Security page states it does not enforce isolation between users in a single process or restrict local disk and network access, so component code runs at the same trust level as the server.", - shortValue: 'Self-hosted only: requirements.txt, uv, or a custom Docker image', + shortValue: 'Yes, self-hosted only: requirements.txt, uv, or a custom Docker image', confidence: 'verified', sources: [ { @@ -811,10 +811,10 @@ export const langflowProfile: CompetitorProfile = { }, sessionPolicy: { value: - 'Partial: on self-hosted deployments only, via environment variables. Langflow issues short-lived JWTs and exposes `LANGFLOW_ACCESS_TOKEN_EXPIRE_SECONDS` (default 3600, one hour) and `LANGFLOW_REFRESH_TOKEN_EXPIRE_SECONDS` (default 604800, seven days), so an operator sets the absolute ceiling on how long a signed-in session survives before re-authentication. No inactivity or idle timeout setting is documented, and no admin-console UI for setting session policy across an organization is documented for Langflow Cloud.', + 'Yes: on self-hosted deployments only, via environment variables. Langflow issues short-lived JWTs and exposes `LANGFLOW_ACCESS_TOKEN_EXPIRE_SECONDS` (default 3600, one hour) and `LANGFLOW_REFRESH_TOKEN_EXPIRE_SECONDS` (default 604800, seven days), so an operator sets the absolute ceiling on how long a signed-in session survives before re-authentication. No inactivity or idle timeout setting is documented, and no admin-console UI for setting session policy across an organization is documented for Langflow Cloud.', detail: 'Expiry is measured from token issuance rather than last activity, and clients silently exchange a refresh token at `/api/v1/refresh`, so the effective session cap is the refresh token lifetime. Because these are process environment variables, the policy is set by whoever operates the deployment rather than by an administrator inside the product.', - shortValue: 'Self-hosted only, via token-expiry env variables', + shortValue: 'Yes, self-hosted only, via token-expiry env variables', confidence: 'verified', sources: [ { diff --git a/apps/sim/lib/compare/data/competitors/make.ts b/apps/sim/lib/compare/data/competitors/make.ts index d85f6158560..d5d71296d48 100644 --- a/apps/sim/lib/compare/data/competitors/make.ts +++ b/apps/sim/lib/compare/data/competitors/make.ts @@ -697,10 +697,10 @@ export const makeProfile: CompetitorProfile = { }, codeSandboxRuntime: { value: - "Partial: Enterprise-only and at the package layer. The Make Code module has an 'Additional dependencies (Enterprise plans only)' field under Advanced settings where third-party JavaScript/Python packages are declared by name (Make's own example adds axios, then requires it in the code) and installed before the code runs. On Core, Pro, and Teams the runtime is a fixed image limited to Make's standard libraries: moment, moment-timezone, and lodash for JavaScript, and pendulum, toolz, and requests for Python. Make's documentation lists no field for OS-level system packages, custom container images, or preinstalled CLI binaries on any plan.", + "Yes: on Enterprise plans only, and at the package layer. The Make Code module has an 'Additional dependencies (Enterprise plans only)' field under Advanced settings where third-party JavaScript/Python packages are declared by name (Make's own example adds axios, then requires it in the code) and installed before the code runs. On Core, Pro, and Teams the runtime is a fixed image limited to Make's standard libraries: moment, moment-timezone, and lodash for JavaScript, and pendulum, toolz, and requests for Python. Make's documentation lists no field for OS-level system packages, custom container images, or preinstalled CLI binaries on any plan.", detail: 'Per the Make Code app documentation, declared dependencies are installed before execution and are not shared between multiple Code modules. The sandbox itself is sized by plan rather than by the user: 1 CPU, 512 MB RAM, and a 30-second maximum execution time on Core/Pro/Teams, rising to 2 CPUs, 1024 MB RAM, and 300 seconds on Enterprise. Runtimes are pinned by Make (Python 3.12.11, Node 20.19.4) rather than chosen per module, and because Make is cloud-only with no self-hosted engine, there is no path to bake a custom runtime image. Make documents the Code app as being in open beta, noting that both functionality and pricing may change.', - shortValue: 'Packages only: declared npm/PyPI dependencies, Enterprise plans', + shortValue: 'Yes: declared npm/PyPI packages only, Enterprise plans', confidence: 'verified', sources: [ { url: 'https://apps.make.com/code', label: 'Make Code app docs', asOf: '2026-08-10' }, diff --git a/apps/sim/lib/compare/data/competitors/microsoft-copilot.ts b/apps/sim/lib/compare/data/competitors/microsoft-copilot.ts index 716d2fe8b9e..d2b60b31eaa 100644 --- a/apps/sim/lib/compare/data/competitors/microsoft-copilot.ts +++ b/apps/sim/lib/compare/data/competitors/microsoft-copilot.ts @@ -1099,10 +1099,11 @@ export const microsoftCopilotProfile: CompetitorProfile = { }, sessionPolicy: { value: - 'Partial: at the Microsoft identity and Power Platform layers rather than in Copilot Studio itself. Microsoft Entra ID Conditional Access sign-in frequency policies let an admin set how long a user can access a resource before signing in again (or require reauthentication every time), and a Power Platform admin can separately turn on Session Expiration (60 to 1,440 minutes) plus an Inactivity timeout (minimum 5 minutes) per environment under Settings > Product > Privacy + Security', + 'Yes: configured at the Microsoft identity and Power Platform layers rather than in Copilot Studio itself. Microsoft Entra ID Conditional Access sign-in frequency policies let an admin set how long a user can access a resource before signing in again (or require reauthentication every time), and a Power Platform admin can separately turn on Session Expiration (60 to 1,440 minutes) plus an Inactivity timeout (minimum 5 minutes) per environment under Settings > Product > Privacy + Security', detail: "Copilot Studio exposes no admin-configurable user-session-lifetime setting of its own and inherits the tenant Entra ID session policy, whose default is a rolling 90-day sign-in frequency window with a 90-day refresh-token expiration. The per-environment Session Expiration and Inactivity timeout settings override that default Entra behavior for the environment, though Microsoft documents them against Dataverse-backed customer engagement apps rather than the Copilot Studio maker portal specifically, and lists apps (including Power Apps canvas apps) that don't enforce them. Conditional Access requires a Microsoft Entra ID P1 or P2 license.", - shortValue: 'Via Entra Conditional Access and per-environment timeouts', + shortValue: + 'Yes: via Entra Conditional Access and per-environment Power Platform timeouts, not Copilot Studio itself', confidence: 'verified', sources: [ { diff --git a/apps/sim/lib/compare/data/competitors/n8n.ts b/apps/sim/lib/compare/data/competitors/n8n.ts index 441e002b667..dae1e87938f 100644 --- a/apps/sim/lib/compare/data/competitors/n8n.ts +++ b/apps/sim/lib/compare/data/competitors/n8n.ts @@ -711,7 +711,7 @@ export const n8nProfile: CompetitorProfile = { }, codeSandboxRuntime: { value: - "Partial: self-hosted only. On a self-hosted instance an admin sets NODE_FUNCTION_ALLOW_BUILTIN to allowlist Node.js built-in modules (by name, or '*' for all) and NODE_FUNCTION_ALLOW_EXTERNAL to allowlist npm packages by name, with those packages sourced from the instance's n8n/node_modules directory; on n8n Cloud the Code node can't import external npm modules, and n8n makes only the crypto built-in and the moment package available.", + "Yes: on self-hosted deployments only, through instance-level environment variables. On a self-hosted instance an admin sets NODE_FUNCTION_ALLOW_BUILTIN to allowlist Node.js built-in modules (by name, or '*' for all) and NODE_FUNCTION_ALLOW_EXTERNAL to allowlist npm packages by name, with those packages sourced from the instance's n8n/node_modules directory; on n8n Cloud the Code node can't import external npm modules, and n8n makes only the crypto built-in and the moment package available.", detail: "The two allowlist variables are instance-level environment variables, not per-workflow settings, and when the instance runs task runners they must be set on the runners rather than the main n8n process. n8n's docs describe the '*' wildcard for the built-in allowlist; the external allowlist is documented as specific module names. Python follows the same host-level pattern: n8n v2 removes the Pyodide-based Python Code node in favour of a native-Python task-runner implementation, and the task-runner variables N8N_RUNNERS_STDLIB_ALLOW and N8N_RUNNERS_EXTERNAL_ALLOW allowlist Python standard-library and third-party modules respectively, so the available Python environment is likewise a property of the host deployment rather than a per-workflow setting. There is no per-code-step declaration of packages, OS packages, or preinstalled CLI binaries; changing the dependency set means changing the host instance.", shortValue: 'Self-hosted env-var allowlist; Cloud is a fixed image', @@ -1064,7 +1064,7 @@ export const n8nProfile: CompetitorProfile = { }, sessionPolicy: { value: - 'Partial: self-hosted only and env-var driven. N8N_USER_MANAGEMENT_JWT_DURATION_HOURS sets how long a signed-in session JWT lasts (default 168 hours, one week) and N8N_USER_MANAGEMENT_JWT_REFRESH_TIMEOUT_HOURS controls sliding refresh, where 0 means refresh at 25% of the duration and -1 disables refresh so the duration becomes a hard re-login deadline.', + 'Yes: on self-hosted deployments only, env-var driven. N8N_USER_MANAGEMENT_JWT_DURATION_HOURS sets how long a signed-in session JWT lasts (default 168 hours, one week) and N8N_USER_MANAGEMENT_JWT_REFRESH_TIMEOUT_HOURS controls sliding refresh, where 0 means refresh at 25% of the duration and -1 disables refresh so the duration becomes a hard re-login deadline.', detail: 'Both are instance-level environment variables set at deploy time rather than an admin console setting, and fractional values (for example 0.5 for 30 minutes) are accepted. The pair was added in n8n 1.26.0 in response to a community request for a session-time limit. Configuring them requires control of the host, so they are not available to n8n Cloud customers, and n8n does not document a Cloud- or Enterprise-tier session-lifetime setting; SAML/OIDC SSO on Business/Enterprise plans handles authentication but n8n does not document inheriting an IdP session lifetime.', shortValue: 'Self-hosted JWT duration env vars, no Cloud setting', diff --git a/apps/sim/lib/compare/data/competitors/openai-agentkit.ts b/apps/sim/lib/compare/data/competitors/openai-agentkit.ts index d66a26c90de..666882d5d18 100644 --- a/apps/sim/lib/compare/data/competitors/openai-agentkit.ts +++ b/apps/sim/lib/compare/data/competitors/openai-agentkit.ts @@ -679,10 +679,10 @@ export const openaiAgentkitProfile: CompetitorProfile = { }, codeSandboxRuntime: { value: - "Partial: configurable only on the code-first path. The Agents SDK's sandbox agents let you name the container image the agent's shell and code run in (the documented Docker example passes image: 'node:22-bookworm-slim' to DockerSandboxClient), so third-party packages, OS packages, and CLI binaries come from an image you build and control. The hosted Code Interpreter tool is the opposite: a fixed OpenAI-managed container whose only user-adjustable setting is the memory tier (1g default, 4g, 16g, 64g), with no documented way to declare pip/npm or system packages.", + "Yes: on the code-first path only, by supplying your own container image. The Agents SDK's sandbox agents let you name the container image the agent's shell and code run in (the documented Docker example passes image: 'node:22-bookworm-slim' to DockerSandboxClient), so third-party packages, OS packages, and CLI binaries come from an image you build and control. The hosted Code Interpreter tool is the opposite: a fixed OpenAI-managed container whose only user-adjustable setting is the memory tier (1g default, 4g, 16g, 64g), with no documented way to declare pip/npm or system packages.", detail: "Sandbox execution runs on infrastructure you supply, not OpenAI's: the documented clients are UnixLocalSandboxClient (macOS/Linux) and DockerSandboxClient for local execution, plus hosted providers via BlaxelSandboxClient, CloudflareSandboxClient, DaytonaSandboxClient, E2BSandboxClient, ModalSandboxClient, RunloopSandboxClient, and VercelSandboxClient. The visual Agent Builder canvas is unaffected either way: its node palette (Start, Agent, Note, File search, Guardrails, MCP, If/else, While, Human approval, Transform, Set state) has no code node, so a no-code builder's only code-execution surface is the fixed Code Interpreter container, which also discards all its data 20 minutes after last use.", - shortValue: 'Agents SDK sandbox image only; Code Interpreter is fixed', + shortValue: 'Custom image via Agents SDK sandboxes; Code Interpreter fixed', confidence: 'verified', sources: [ { @@ -1038,7 +1038,7 @@ export const openaiAgentkitProfile: CompetitorProfile = { }, sessionPolicy: { value: - "Not publicly documented: OpenAI does not document an admin-configurable session lifetime or inactivity timeout for ChatGPT workspaces or the API Platform. The workspace identity controls it does document are SSO/SAML, domain verification, SCIM provisioning, MFA enforcement through the identity provider, and RBAC, so how often members must re-authenticate is set at the upstream IdP rather than by a policy in OpenAI's admin console.", + "No: OpenAI does not document an admin-configurable session lifetime or inactivity timeout for ChatGPT workspaces or the API Platform, so there is no documented way for an admin to shorten how long a signed-in session lasts. The workspace identity controls it does document are SSO/SAML, domain verification, SCIM provisioning, MFA enforcement through the identity provider, and RBAC, so how often members must re-authenticate is set at the upstream IdP rather than by a policy in OpenAI's admin console.", detail: "OpenAI's admin rollout guide and Work admin FAQ enumerate identity, access-governance, and compliance controls without a session-duration or idle-timeout setting, and the Codex authentication documentation describes tokens being refreshed automatically during active use ('Codex refreshes tokens automatically during use before they expire, so active sessions usually continue without requiring another browser login') rather than an absolute cap an admin can shorten. No session policy specific to AgentKit or Agent Builder is published.", shortValue: 'No documented admin session lifetime or idle timeout', diff --git a/apps/sim/lib/compare/data/competitors/openclaw.ts b/apps/sim/lib/compare/data/competitors/openclaw.ts index ad3b531b36b..d95158594f2 100644 --- a/apps/sim/lib/compare/data/competitors/openclaw.ts +++ b/apps/sim/lib/compare/data/competitors/openclaw.ts @@ -981,10 +981,10 @@ export const openClawProfile: CompetitorProfile = { }, sessionPolicy: { value: - 'Not applicable: there is no signed-in session to bound. The Gateway authenticates callers with a static shared secret (`gateway.auth` token or password, or a trusted-proxy header mode), and the security docs document no session expiry, idle timeout, or time-bound signed session; every authenticated caller holds operator-level access until the secret is rotated.', + 'No: OpenClaw has no signed-in session concept to bound, so this is a category difference rather than a missing setting. The Gateway authenticates callers with a static shared secret (`gateway.auth` token or password, or a trusted-proxy header mode), and the security docs document no session expiry, idle timeout, or time-bound signed session; every authenticated caller holds operator-level access until the secret is rotated.', detail: 'The `session.reset` settings that do exist govern conversation context, not authentication: `session.reset.mode` of `"daily"` (`atHour`, default 4) or `"idle"` (`idleMinutes`) starts a fresh chat session, and cron jobs get a fresh conversation session per run. The docs state `sessionKey` is "a routing selector, not an authorization token," and recommend separate Gateway instances per trust boundary rather than session controls inside one shared instance.', - shortValue: 'No signed-in session: static shared-secret operator auth', + shortValue: 'No: no signed-in session; static shared-secret operator auth', confidence: 'verified', sources: [ { diff --git a/apps/sim/lib/compare/data/competitors/pipedream.ts b/apps/sim/lib/compare/data/competitors/pipedream.ts index ebfce7c7a49..61bead7321f 100644 --- a/apps/sim/lib/compare/data/competitors/pipedream.ts +++ b/apps/sim/lib/compare/data/competitors/pipedream.ts @@ -575,7 +575,7 @@ export const pipedreamProfile: CompetitorProfile = { }, codeSandboxRuntime: { value: - 'Partial: at the package layer only. A code step declares its own third-party dependencies inline, any npm package in Node.js (`import axios from "axios@0.19.2"` pins an exact version, and `^`/`~` ranges are accepted) and any PyPI package in Python (`import requests`, with `# pipedream add-package pandas==2.0.0` to pin), with no package.json or requirements.txt to maintain. The OS layer underneath is not user-configurable — there is no custom image, Dockerfile, or apt-level control: Bash steps ship a Pipedream-chosen set of binaries (curl, jq, git), and the docs state that packages needing binaries or system libraries absent from the execution environment are unsupported.', + 'Yes: at the package layer only. A code step declares its own third-party dependencies inline, any npm package in Node.js (`import axios from "axios@0.19.2"` pins an exact version, and `^`/`~` ranges are accepted) and any PyPI package in Python (`import requests`, with `# pipedream add-package pandas==2.0.0` to pin), with no package.json or requirements.txt to maintain. The OS layer underneath is not user-configurable — there is no custom image, Dockerfile, or apt-level control: Bash steps ship a Pipedream-chosen set of binaries (curl, jq, git), and the docs state that packages needing binaries or system libraries absent from the execution environment are unsupported.', detail: 'Pipedream\'s docs are explicit that workflows start with no packages installed and that importing a module is what makes it available for that step, so the dependency set is genuinely user-controlled per step rather than a vendor-curated allowlist. System-level configuration is not exposed: Pipedream\'s Python docs say of packages requiring environment binaries that "we cannot support these types of packages at this time," and the Bash docs direct users who need a package preinstalled to file a support request, with downloading and building software into the 2GB `/tmp` scratch directory at run time as the only self-service workaround. There is no custom-image, Dockerfile, or apt-level configuration, and because Pipedream is cloud-hosted only there is no self-hosted runtime a team could rebuild instead.', shortValue: 'Packages only: any npm or PyPI dependency, fixed OS image', @@ -907,7 +907,7 @@ export const pipedreamProfile: CompetitorProfile = { }, sessionPolicy: { value: - "Not publicly documented: Pipedream's workspace administration and SSO documentation enumerates the security controls available to admins — requiring two-factor authentication for all members, configuring SAML/Google/Okta SSO, SCIM provisioning, and managing verified domains, all on the Business plan — and includes no absolute session lifetime, idle timeout, or forced re-authentication interval. Pipedream also does not publish a fixed session length for the dashboard, so the absence of an admin control is inferred from the documentation rather than stated by Pipedream.", + 'No: Pipedream publishes no admin-configurable session lifetime, idle timeout, or forced re-authentication interval. Its workspace administration and SSO documentation enumerates the security controls available to admins — requiring two-factor authentication for all members, configuring SAML/Google/Okta SSO, SCIM provisioning, and managing verified domains, all on the Business plan — and includes no session-duration control among them. Pipedream also does not publish a fixed session length for the dashboard, so the absence of an admin control is inferred from the documentation rather than stated by Pipedream.', detail: "Neither the workspace administration docs, the SSO overview, nor the Privacy and Security page mentions session duration, idle timeout, or re-authentication frequency; the only session-related announcement Pipedream has published was a one-time invalidation of all login sessions during a September 2021 maintenance window, which stated no ongoing policy. Workspaces on SSO inherit whatever re-authentication cadence the upstream identity provider enforces, but that is the IdP's policy rather than a Pipedream-side control. The one expiration Pipedream does publish covers API credentials rather than signed-in user sessions: REST API OAuth access tokens expire after 1 hour.", shortValue: 'No documented admin session lifetime or idle timeout', diff --git a/apps/sim/lib/compare/data/competitors/power-automate.ts b/apps/sim/lib/compare/data/competitors/power-automate.ts index dc080a88d1d..73c64071826 100644 --- a/apps/sim/lib/compare/data/competitors/power-automate.ts +++ b/apps/sim/lib/compare/data/competitors/power-automate.ts @@ -751,10 +751,10 @@ export const powerAutomateProfile: CompetitorProfile = { }, codeSandboxRuntime: { value: - 'No: the code surface Power Platform exposes runs on a fixed, Microsoft-curated runtime. Custom connector code is C# against .NET Standard 2.0, and Microsoft states the environment is closed — "Not all C# namespaces are supported. Currently, you can use functions from the following namespaces only" — with one script file per connector, capped at 1 MB, and no mechanism to declare third-party packages or system packages. Microsoft\'s developer guidance routes custom server-side logic out of the product instead, to custom connectors and Azure Functions ("Build Azure Functions: Craft Azure Functions to extend apps with custom server-side logic"), whose dependencies are managed in Azure; an Office Script invoked through the Excel Online (Business) "Run script" action likewise runs in the Office Scripts runtime. The scripting actions in Power Automate for desktop do accept externally supplied dependencies (the Run Python script action takes "Module folder paths", documented as "the paths of folders where external Python modules lie", and Run .NET script takes a "References to be loaded" root path for .dll files), but the Python version is limited to a choice of 2.7 or 3.4, dependencies must be pre-staged on disk rather than declared as a package manifest, and those actions run on a customer-managed Windows machine rather than in a managed cloud runtime.', + 'Yes: on Power Automate for desktop only, whose scripting actions accept externally supplied dependencies — the Run Python script action takes "Module folder paths", documented as "the paths of folders where external Python modules lie", and Run .NET script takes a "References to be loaded" root path for .dll files. The constraints are substantial: the Python version is limited to a choice of 2.7 or 3.4, dependencies must be pre-staged on disk rather than declared as a package manifest, and those actions run on a customer-managed Windows machine rather than in a managed cloud runtime. The hosted cloud code surface has no equivalent: custom connector code is C# against .NET Standard 2.0, and Microsoft states the environment is closed — "Not all C# namespaces are supported. Currently, you can use functions from the following namespaces only" — with one script file per connector, capped at 1 MB, and no mechanism to declare third-party packages or system packages. Microsoft\'s developer guidance routes custom server-side logic out of the product instead, to custom connectors and Azure Functions ("Build Azure Functions: Craft Azure Functions to extend apps with custom server-side logic"), whose dependencies are managed in Azure; an Office Script invoked through the Excel Online (Business) "Run script" action likewise runs in the fixed Office Scripts runtime.', detail: - 'Power Automate for desktop also supports environment-level custom actions: an organization uploads signed .dll files plus their dependency .dll files as a .cab package, capped at 30 MB per custom action group, and all dependencies used in custom actions must be the same version as those in Power Automate for desktop itself. That is assembly-level extension of a locally installed runtime rather than a declarative package/system-package manifest for a hosted sandbox. Microsoft states the constraint affirmatively for the in-product code surface rather than merely omitting the feature: the supported namespace list for custom connector code is enumerated and closed, and the supported .NET version is pinned to .NET Standard 2.0.', - shortValue: 'No configurable sandbox; desktop scripts run on customer machines', + 'Power Automate for desktop also supports environment-level custom actions: an organization uploads signed .dll files plus their dependency .dll files as a .cab package, capped at 30 MB per custom action group, and all dependencies used in custom actions must be the same version as those in Power Automate for desktop itself. That is assembly-level extension of a locally installed runtime rather than a declarative package/system-package manifest for a hosted sandbox. For the in-product cloud code surface Microsoft states the constraint affirmatively rather than merely omitting the feature: the supported namespace list for custom connector code is enumerated and closed, and the supported .NET version is pinned to .NET Standard 2.0.', + shortValue: 'Desktop scripting actions load external modules; cloud runtime is fixed', confidence: 'verified', sources: [ { @@ -1100,7 +1100,7 @@ export const powerAutomateProfile: CompetitorProfile = { }, sessionPolicy: { value: - 'Partial: an admin can turn on Session Expiration per environment from the Power Platform admin center (Settings > Product > Privacy + Security) and set a maximum session length between 60 and 1,440 minutes (24 hours) plus a timeout warning of at least 20 minutes, and separately turn on an Inactivity timeout from a minimum of 5 minutes up to less than the session length. Both apply to all users in the environment and override the default Microsoft Entra ID session policy, which itself is admin-configurable through Conditional Access sign-in frequency (default a rolling 90-day window, requiring an Entra ID P1 or P2 license). The qualifier is scope: Microsoft frames these settings as protecting "customer engagement apps, such as Dynamics 365 Sales, Dynamics 365 Customer Service" and Dataverse, and names first-party surfaces that do not enforce them; enforcement for the Power Automate maker portal itself is not documented on that page.', + 'Yes: an admin can turn on Session Expiration per environment from the Power Platform admin center (Settings > Product > Privacy + Security) and set a maximum session length between 60 and 1,440 minutes (24 hours) plus a timeout warning of at least 20 minutes, and separately turn on an Inactivity timeout from a minimum of 5 minutes up to less than the session length. Both apply to all users in the environment and override the default Microsoft Entra ID session policy, which itself is admin-configurable through Conditional Access sign-in frequency (default a rolling 90-day window, requiring an Entra ID P1 or P2 license). The qualifier is scope: Microsoft frames these settings as protecting "customer engagement apps, such as Dynamics 365 Sales, Dynamics 365 Customer Service" and Dataverse, and names first-party surfaces that do not enforce them; enforcement for the Power Automate maker portal itself is not documented on that page.', detail: 'Microsoft documents these settings for Dataverse and the customer engagement apps, and lists surfaces that do not enforce them, including Power Apps canvas apps, Dynamics 365 for Outlook, and the Dynamics 365 phone and tablet apps. Changed values take effect the next time a user signs in; session timeout is enforced server-side while inactivity timeout is a client-side sign-out.', shortValue: 'Per-environment timeouts, documented for Dataverse and Dynamics 365 apps', diff --git a/apps/sim/lib/compare/data/competitors/retool.ts b/apps/sim/lib/compare/data/competitors/retool.ts index 5f4fb90bfb3..13de19374c1 100644 --- a/apps/sim/lib/compare/data/competitors/retool.ts +++ b/apps/sim/lib/compare/data/competitors/retool.ts @@ -663,10 +663,10 @@ export const retoolProfile: CompetitorProfile = { }, codeSandboxRuntime: { value: - 'Partial: the dependency set of a workflow Code block is user-configurable, but only at the package layer. In the workflow editor\'s Libraries tab, "Add Python library" picks from Retool\'s built-in library set, and "Modify requirements.txt" declares an arbitrary list of public PyPI packages with pinned versions; the JavaScript equivalent adds public npm packages via "Modify package.json". Package-level configuration only: there is no documented way to declare OS-level system packages or preinstalled CLI binaries for the runtime.', + 'Yes: the dependency set of a workflow Code block is user-configurable, though only at the package layer. In the workflow editor\'s Libraries tab, "Add Python library" picks from Retool\'s built-in library set, and "Modify requirements.txt" declares an arbitrary list of public PyPI packages with pinned versions; the JavaScript equivalent adds public npm packages via "Modify package.json". Package-level configuration only: there is no documented way to declare OS-level system packages or preinstalled CLI binaries for the runtime.', detail: 'Beyond the preloaded set (Lodash, Moment.js, UUID, Numbro, and PapaParse are the JavaScript libraries Retool documents by name; the Python built-in set is not enumerated in the docs, which describe "built-in support for many popular libraries" and expose the list only through an interactive browser), builders add their own dependencies per workflow. Private npm/PyPI registries are self-hosted only and require a configured code-executor service, the container that runs user-defined JavaScript and Python with installed custom libraries; Retool sandboxes environment creation with NsJail, which needs privileged container access, and self-hosted operators can disable that sandboxing entirely with CONTAINER_UNPRIVILEGED_MODE.', - shortValue: 'Packages only: per-workflow PyPI and npm libraries', + shortValue: 'Yes, packages only: per-workflow PyPI and npm libraries', confidence: 'verified', sources: [ { @@ -973,10 +973,10 @@ export const retoolProfile: CompetitorProfile = { }, sessionPolicy: { value: - 'Partial: an absolute session lifetime cap is configurable, but the cloud control is coarse and lives inside SSO settings. Toggling "Use short session" in the organization\'s Single Sign On settings drops the session length from one week to 12 hours. Self-hosted deployments get finer control through SESSION_DURATION_MINUTES, which sets an arbitrary custom session duration in minutes (default 10080, or 720 when USE_SHORT_SESSIONS is true). No inactivity or idle timeout is documented.', + 'Yes: an absolute session lifetime cap is configurable, though the cloud control is coarse and lives inside SSO settings. Toggling "Use short session" in the organization\'s Single Sign On settings drops the session length from one week to 12 hours. Self-hosted deployments get finer control through SESSION_DURATION_MINUTES, which sets an arbitrary custom session duration in minutes (default 10080, or 720 when USE_SHORT_SESSIONS is true). No inactivity or idle timeout is documented.', detail: "The documented policy is an absolute cap measured from sign-in, not an idle timer, so an active or idle browser session persists until the cap expires. Cloud orgs choose between the two fixed values (one week or 12 hours); only self-hosted operators can specify a duration of their own. Retool's pricing page lists Custom SSO (SAML/OpenID) under Enterprise and does not list Google SSO at any tier, and Retool's documentation does not state which plans can reach the short-session toggle. A Retool staff member states on the community forum that configuring Google SSO, which exposes the same short-session control, does not require the Enterprise plan; that is not confirmed in Retool's official documentation.", - shortValue: 'Absolute cap only, coarse on cloud; no idle timeout', + shortValue: 'Yes, absolute cap only, coarse on cloud; no idle timeout', confidence: 'estimated', sources: [ { diff --git a/apps/sim/lib/compare/data/competitors/stackai.ts b/apps/sim/lib/compare/data/competitors/stackai.ts index 31f4adff439..27998d32ea0 100644 --- a/apps/sim/lib/compare/data/competitors/stackai.ts +++ b/apps/sim/lib/compare/data/competitors/stackai.ts @@ -594,7 +594,7 @@ export const stackaiProfile: CompetitorProfile = { }, codeSandboxRuntime: { value: - 'Partial: at the package layer only. The newer Code Node exposes a Dependencies field, documented as "a list of package names that get installed into the sandbox before your code runs," so builders declare third-party Python/TypeScript packages per node. The deprecated Python Code node it replaces is a fixed image restricted to a vendor-curated set of pre-imported libraries.', + 'Yes: at the package layer only. The newer Code Node exposes a Dependencies field, documented as "a list of package names that get installed into the sandbox before your code runs," so builders declare third-party Python/TypeScript packages per node. The deprecated Python Code node it replaces is a fixed image restricted to a vendor-curated set of pre-imported libraries.', detail: 'Code Node runs in an isolated sandbox with /home/user as the working directory; StackAI\'s docs contrast it with the Python Code node as "Allows importing custom libraries" versus "Restricted to pre-imported libraries." That older node\'s fixed set covers pandas, numpy, requests, BeautifulSoup, matplotlib, plotly, pypdf, sklearn, tiktoken, and weaviate among others, with no way to add to it. Dependency declaration is package-level only — StackAI does not document declaring OS-level system packages or preinstalled CLI binaries, and dependencies add sandbox startup time. Sandbox isolation is provided by E2B, which runs each execution as an isolated VM.', shortValue: 'Packages only: per-node dependencies on the Code Node', @@ -846,10 +846,10 @@ export const stackaiProfile: CompetitorProfile = { }, sessionPolicy: { value: - "Not publicly documented: no admin-configurable session lifetime or idle timeout appears in StackAI's public documentation. Its Authentication and MFA page covers password login, org-wide MFA enforcement, and SSO, and the Feature Access page enumerating org-level admin settings (MFA, LLM access, app/tool availability, knowledge bases, advanced features) lists no session control.", + "No: no admin-configurable session lifetime or idle timeout appears in StackAI's public documentation. Its Authentication and MFA page covers password login, org-wide MFA enforcement, and SSO, and the Feature Access page enumerating org-level admin settings (MFA, LLM access, app/tool availability, knowledge bases, advanced features) lists no session control.", detail: "Where SSO is used, StackAI states MFA enforcement happens at the identity provider, so an organization's effective re-authentication cadence is inherited from its upstream IdP rather than set in StackAI. No fixed session length is published either, and the Trust Center lists access-control and termination policies without any session-timeout control.", - shortValue: 'Not publicly documented', + shortValue: 'No documented session lifetime or idle timeout control', confidence: 'estimated', sources: [ { diff --git a/apps/sim/lib/compare/data/competitors/vellum.ts b/apps/sim/lib/compare/data/competitors/vellum.ts index 1b9046b0dfc..e990ca0d73f 100644 --- a/apps/sim/lib/compare/data/competitors/vellum.ts +++ b/apps/sim/lib/compare/data/competitors/vellum.ts @@ -907,7 +907,7 @@ export const vellumProfile: CompetitorProfile = { }, sessionPolicy: { value: - 'Not publicly documented: no admin-configurable session lifetime cap or idle timeout is documented for Vellum workspaces. The docs index lists four security pages (Data Privacy and Storage, HMAC Authentication, RBAC, Static IPs) and two organization-settings pages (Manage Organization Access, Data Retention Policies), none of which describe session length, inactivity expiry, or forced re-authentication; the only admin-configurable access controls documented are workspace roles and domain-based automatic join.', + 'No: no admin-configurable session lifetime cap or idle timeout is documented for Vellum workspaces on any deployment mode. The docs index lists four security pages (Data Privacy and Storage, HMAC Authentication, RBAC, Static IPs) and two organization-settings pages (Manage Organization Access, Data Retention Policies), none of which describe session length, inactivity expiry, or forced re-authentication; the only admin-configurable access controls documented are workspace roles and domain-based automatic join.', detail: 'The Manage Organization Access page covers only domain-based automatic join and the verified-domain list. The Data Privacy and Storage page references RBAC and HMAC authentication for API access but says nothing about interactive session duration. No first-party SAML/OIDC setup page exists either, so an inherited IdP session policy cannot be confirmed as available.', shortValue: 'No documented session lifetime or idle timeout controls', diff --git a/apps/sim/lib/compare/data/competitors/zapier.ts b/apps/sim/lib/compare/data/competitors/zapier.ts index 55632637da7..2eaeaf100d1 100644 --- a/apps/sim/lib/compare/data/competitors/zapier.ts +++ b/apps/sim/lib/compare/data/competitors/zapier.ts @@ -662,10 +662,10 @@ export const zapierProfile: CompetitorProfile = { }, codeSandboxRuntime: { value: - 'Partial: at the package level only. Code by Zapier lets a builder declare public npm (JavaScript) or PyPI (Python) packages for a Code step from a Packages panel in the editor, optionally pinned to a version, on Professional, Team, and Enterprise plans. There is no control over OS-level system packages or preinstalled CLI binaries, and private registries are not supported.', + 'Yes: at the package level only. Code by Zapier lets a builder declare public npm (JavaScript) or PyPI (Python) packages for a Code step from a Packages panel in the editor, optionally pinned to a version, on Professional, Team, and Enterprise plans. There is no control over OS-level system packages or preinstalled CLI binaries, and private registries are not supported.', detail: 'The standard Node.js library and fetch are available by default. Zapier documents three constraints on what can be declared: only ESM JavaScript packages work (CommonJS-only packages do not), native modules requiring compiled binaries or system-level access do not work, and installs must finish within 30 seconds (120 seconds on Enterprise) inside a 512 MB memory ceiling on all plans. The Free plan cannot use third-party packages at all.', - shortValue: 'Packages only: public npm/PyPI on paid plans, no OS-level control', + shortValue: 'Yes: packages only, public npm/PyPI on paid plans, no OS-level control', confidence: 'verified', sources: [ { diff --git a/apps/sim/lib/compare/data/sim.ts b/apps/sim/lib/compare/data/sim.ts index 0aadd0a9ba3..048a057a2b3 100644 --- a/apps/sim/lib/compare/data/sim.ts +++ b/apps/sim/lib/compare/data/sim.ts @@ -684,10 +684,10 @@ export const simProfile: CompetitorProfile = { }, codeSandboxRuntime: { value: - 'Yes: named sandboxes a workspace maintains and a Function block selects, each declaring a language, its pip or npm dependencies, optional Debian/APT system packages, and optional managed CLI tools from a catalog grouped by cloud, Kubernetes, infrastructure, deployment, data and storage, and security tools; on sim.ai they require an active Max or Enterprise plan', + 'Yes: on sim.ai this requires an active Max or Enterprise plan, and it works through named sandboxes a workspace maintains and a Function block selects, each declaring a language, its pip or npm dependencies, optional Debian/APT system packages, and optional managed CLI tools from a catalog grouped by cloud, Kubernetes, infrastructure, deployment, data and storage, and security tools', detail: 'Only workspace admins can create or edit sandboxes, in Settings → Sandboxes. On sim.ai each specification is prebuilt into a reusable image so runs pay no install cost; a self-hosted deployment using Daytona installs the dependencies, system packages, and managed CLI tools inside the sandbox at the start of every run instead, and prebuilt images require E2B. Two sandboxes with the same language, dependency list, system packages, and managed CLI tools share one build. Every managed CLI entry uses a pinned, integrity-checked vendor artifact. Self-hosted deployments turn sandboxes on with SANDBOXES_ENABLED, and additionally need a remote execution provider and a dedicated Function base image configured. With no sandbox selected, remote code runs on the dedicated Function base; import-free JavaScript stays in the local isolated runtime and ignores the sandbox selection either way.', - shortValue: 'Named sandboxes: packages, system packages, managed CLIs', + shortValue: 'Named sandboxes (Max/Enterprise): packages, system packages, CLIs', confidence: 'verified', sources: [ { @@ -1024,7 +1024,7 @@ export const simProfile: CompetitorProfile = { 'Yes: Enterprise organization owners and admins can set a max session lifetime (1 to 8,760 hours from sign-in, regardless of activity) and an idle timeout (48 to 8,760 hours without activity), applied to every member on every device', detail: 'Both limits are optional; leaving them empty keeps the default of 30-day sessions that extend automatically while a member stays active. A separate "Sign out all members" action immediately revokes every member session in the organization except the admin\'s own, for use after a security incident or an offboarding wave. The 48-hour idle floor exists because session activity is recorded at most once per day, so a shorter window could sign out members who are actively working.', - shortValue: 'Max session lifetime and idle timeout, applied org-wide', + shortValue: 'Enterprise: max session lifetime and idle timeout, org-wide', confidence: 'verified', sources: [ {