feat: render integration base + 2 components

[forestileao]

Summary

Add a new Render integration to SuperPlane with:

• API key connection (optional workspace ID)
• On Event trigger from Render webhooks
• Trigger Deploy action for Render services

What’s included

• Backend integration (pkg/integrations/render/*)
• Render API client (services, owners, webhooks, deploy trigger)
• Automatic webhook provisioning/cleanup through Render API
• Webhook signature verification (webhook-id, webhook-timestamp, webhook-signature)
• Frontend mappers + icon + registry wiring for Render components/triggers
• New docs page: docs/components/Render.mdx
• Sidebar order updates for docs components

Video showing the implementation

Screen.Recording.2026-02-06.at.01.17.31.mp4

[cloudflare-workers-and-pages]

Deploying superplane with    Cloudflare Pages

Latest commit:	74346eb
Status:	✅  Deploy successful!
Preview URL:	https://675b86fe.superplane.pages.dev
Branch Preview URL:	https://feat-render-integration.superplane.pages.dev

View logs

[shiroyasha]

@forestileao

1/ Does it work if you set up two different nodes to listen to different events, or will the web hooks clash?
2/ Will it create one, or multiple web hooks?
3/ Having a single On Event component that covers 10+ events is different to how we were doing things for other integrations. cc @lucaspin want to hear your opinion here as well

[forestileao]

@shiroyasha
1 - It works with no problem using the same webhook

2 - It reuses the same webhook

3 - I think we should not have one component for each, since the payload is very simple and we have 55+ events to cover

[lucaspin]

Having a single On Event component that covers 10+ events is different to how we were doing things for other integrations

I think we shouldn't have a single onEvent trigger here.

The way I like to think about triggers is: a trigger is always scoped to a (1) specific resource type, (2) specific resource, (3) some additional things. Examples:

• semaphore.onPipelineDone -> we select the project (resource type + resource)
• github.onPush -> we select the repository (resource type + resource), and we have filters for the refs (additional things).
• pagerduty.onIncident -> we select the service (resource type + resource)

The reason for that is: what dictates what you need to do after receiving an event is usually the resource type. If you received all events through the same trigger, you'd need a filter after it to route build events to one path, and deploy events to another path.

For example, for Render, we have Builds and we have Deploys. Those are two different resource types. If I receive an event for a Build, I do something completely different than I would do if I received an event for a Deploy. And we can see that in the screenshot you shared: you have two triggers, one for deploy events, one for build events. So, what I'd propose here is to have triggers per resource: render.onDeployEvent, render.onBuildEvent, ...

I'm ok with not having a different trigger per event, e.g. render.onDeployStarted,render.onDeployFinished, but I do think we need to have triggers per resource type at least. The states, we can configure through a MultiSelect, similar to how we select the states in github.onPullRequest trigger.

[lucaspin]

Also additional note: we should always aim to share webhooks, if they use the same underlying event configuration. That's what CompareWebhookConfig() is for. For example, for the GH triggers, if we have two github.onPush triggers, one for main branch, and one for release branches, both of those triggers use the same webhook in GH.

[forestileao]

@lucaspin Trigger per Resource Type!! That make total sense!

[lucaspin]

Also, additional note: if filters are part of the trigger, we should always have a the default filter for the most common use case. Two reasons for this: (1) easier for the user to configure, (2) we don't produce unnecessary events to the system. For example, the default github.onPush filter is for commits on the main branch.

[forestileao]

@lucaspin I think for this specific one will be required to use one webhook for everything

The problem is that can use only one per canvas

[lucaspin]

@forestileao is there a way to know which plan the workspace configured in the integration is in? We might use different strategy depending on it

The problem is that can use only one per canvas

Why one per canvas? It would be one for the integration itself, no?

[forestileao]

Yes, sorry, one per integration.
But no, they don't have an API for billing and plans as far as I researched
@lucaspin

[lucaspin]

Moved the discussion here to involve more people

[forestileao]

Updated the PR with:

1. Mergeable webhook configuration

• Added a mergeable webhook configuration flow so existing webhooks can be updated with newly requested event types.
• This prevents creating extra webhooks and avoids subscribing to all events when not needed..

2. Plan-based webhook strategy

• Professional: uses a single shared webhook for the integration.
• Organization / Enterprise: uses resource-type webhooks (for example, deploy and build).
• This keeps webhook behavior aligned with Render plan capabilities while reducing unnecessary event traffic.

[forestileao]

Video of the webhook flow:

Screen.Recording.2026-02-07.at.12.06.20.mp4

[forestileao]

@lucaspin @shiroyasha Added new Outputs channel (success and fail). Also, renamed trigger_deploy to just deploy and udpated its behavior to only show its final state once deploy is finished.

Note: I needed to inject HTTP and integration context into the webhook context because the render event webhook only sends the eventId and not the deploy id in its payload. So I needed to fetch the event using a GET request to /events/{event} to finally get the deploy Status

[forestileao]

@lucaspin update: added deployId and BuildId to the payloads.

Also added a comment to avoid using http context on webhook nide context