Vibe App Scannern8n integration
n8n Cloud approval pendingMake security checks part of your n8n workflow.
Connect an approved deployment event to a VAS website scan. Bring finding counts, coverage notes and the report link back into your workflow, so your team can decide what to fix next.
Native node available on npm for self-hosted n8n. Not yet verified or available as a native node on n8n Cloud.
Deployment event
Approved project · successful release
VAS website scan
Stable deployment ID · explicit permission
Bounded status checks
Read the same scan · stop at the limit
Team notification
Finding counts · coverage notes · report link
A lifecycle result and a human review—not an automatic security approval.
Connect your workflow
Choose how you use n8n
Native node available
Self-hosted n8n
Ask your n8n owner or admin to install this exact package from Settings → Community nodes:
n8n-nodes-vibe-app-scanner@0.1.0
This is an unverified community package. It runs third-party code in your instance. Review the source and try a disposable instance first.
Native node approval pending
n8n Cloud
The native node has passed automated review and is now in manual review. It is not yet available through the n8n Cloud node picker. Approval and timing are not guaranteed.
You can use n8n’s built-in HTTP Request nodes with the VAS REST API today. That is a separate connection method—not native-node installation or n8n verification.
Both methods require an eligible VAS account, scoped API credentials and available scan allowance. Store keys in n8n credentials, never in workflow JSON.
Ask about HTTP workflow setupStart with an existing report and a scan:read key. The credential test only checks read access; it does not start a scan or confirm scan-creation allowance.
Try an existing report first
Send a report to Slack—without starting another scan
Follow the read-only tutorial, preview finding counts and coverage, then choose whether to send a Slack message. Both templates are manual and inactive, with reading disabled and Slack delivery off by default.
The HTTP template uses built-in nodes on n8n Cloud or self-hosted n8n. The native template requires self-hosted n8n and the VAS package. n8n Cloud approval pending. Neither template contains a scan-creation operation.
How it works
From deployment event to a report your team can review
Your deployment is automated. The follow-up check shouldn’t depend on memory. Use your existing n8n workflow to connect the event, the scan and the people who review the result.
Choose the deployment
Verify your provider’s event. Filter to one approved project, environment and successful deployment. Keep the app origin fixed.
Start or reuse its scan
Pass the provider’s stable deployment ID. Confirm permission and terms, then use an eligible VAS REST API key.
Wait, then read status
Use n8n’s Wait and IF nodes with a deadline and maximum number of reads. Polling never starts a replacement scan.
Notify your team
Send finding counts, coverage notes and the report link to your notification step. The example workflow uses Slack.
Keep the decision with your team
Findings, with the caveats
A completed scan can still have partial, skipped or unavailable checks. Keep independent finding counts alongside those limits. Missing data stays unknown—not zero.
Retries tied to one deployment
A stable deployment ID returns the original scan for the same account and settings. Status checks only read it. A failed scan does not trigger a replacement.
Less detail in notifications
The node leaves finding descriptions, source and raw provider errors out of its output. Your n8n input storage, credentials, retention and notification settings still need review.
Three operations.
No extra AI agent.
A thin native community node for website standard/quick scans. Use n8n’s existing triggers, Wait, IF and notification steps around it.
- Start Deployment Scan
- Admit or reuse a scan for one stable deployment event.
- Get Scan Status
- Read progress, finding counts and coverage without restarting a scan.
- Get Scan Summary
- Read a coverage-aware summary and report link, with no separate model call.
Availability
Published on npm. Cloud review is separate.
Version 0.1.0 has been installed from npm in a disposable self-hosted n8n instance. Credential testing, status reads and summaries passed using an existing test-account report. A separate manual HTTP workflow pilot on n8n Cloud exercised scan admission, polling and Slack delivery.
Those checks do not establish native n8n Cloud availability. The demo is submitted and manual review is pending. There is no confirmed approval date, and live deployment-provider ingress is a separate setup step.
This is a VAS-built integration, not an n8n endorsement or official partnership.
Before you connect
Can I install this on n8n Cloud now?
Not as a native Cloud node yet. Version 0.1.0 is published on npm for self-hosted n8n. Automated review has passed and the demo has been submitted for manual review, but n8n Cloud approval is still pending. There is no confirmed approval date. On Cloud, you can connect to the VAS REST API with built-in HTTP Request nodes instead; that does not install the native node.
How do I install the native node on self-hosted n8n?
An n8n owner or admin can install n8n-nodes-vibe-app-scanner@0.1.0 from Settings → Community nodes. It is an unverified community package, which runs third-party code inside your n8n instance. Review the source and test it in a disposable instance before production use. Installation alone does not enable scans or configure credentials.
Does this scan my n8n workflow or n8n server?
No. This MVP connects n8n to VAS website standard/quick scans for a fixed app origin you own or may test. It does not audit n8n workflow JSON, the n8n platform, GitHub repositories or ZIP uploads, and it does not run deep scans.
Which VAS account and API key do I need?
You need an account eligible for VAS REST API access. Reading requires scan:read; starting scans also requires scan:create, explicit permission/terms and available scan allowance. ChatGPT/MCP access alone does not grant REST API access. Existing account and report-access controls still apply.
Does retrying start another scan?
The new endpoint returns the original scan for the same account, event namespace, deployment ID and settings. Keep the target, retention setting and terms unchanged. The identity lasts while the scan row exists; deleting or purging it removes that identity. Different deployment IDs are separate events. Never generate a new ID to work around an error. Notification redelivery can still produce duplicate messages.
Does it block deployments or fix findings automatically?
No. The example runs after a successful deployment and leaves the review decision with your team. It does not modify your app, suppress findings, deploy fixes or automatically approve a release. Failed, cancelled or timed-out scans do not trigger replacement scans.
Does completed or zero findings mean the app is secure?
No. Completion is a lifecycle state, not a security certification. A completed scan can still have partial, skipped or unavailable checks. Missing counts and coverage stay unknown—not zero. Review the assessed scope, coverage limits and unresolved results in the report.
Does the integration add AI costs?
The node adds no AI agent or separate summarization model call. Normal VAS scan allowances/costs and your n8n or notification-service charges still apply. This is not a claim that scans or hosting are free.
Put the check next to the deployment—not on another to-do list.
Review the inactive deployment-to-Slack example, configure the approved app and credentials, and enable it only when your event checks and permissions are ready.
Native example for self-hosted n8n. n8n Cloud approval pending. Importing the example does not enable scanning.