Skip to content
Configuration

Application changes

What a pull request adds, removes or changes about the application — the variables it reads, the services it uses, the resources it requires — and what its preview still needs.

GitHub shows which lines a pull request changed. Kuppit shows what those lines mean for the running application: a variable the code began reading, a service it started using, a database it now requires — and whether the preview that runs it has them. The same read tells every environment what its commit reads and has not configured.

What Kuppit compares

Every deployment's commit is analysed beside the build — never in its way, and never delaying or failing it. For a pull request, the commit is compared with its merge base: the commit the pull request branched from, as GitHub's own diff measures it. Kuppit reads, for each service:

It readsExample
The variable names the code reads, or an example environment file listsRESEND_API_KEY, NEW_INTERNAL_API_URL
The external services it usesResend, Stripe
The resources it requires, and the names it reads them throughPostgreSQL through DATABASE_URL

Names only, never a value. A variable Kuppit recognises as a service's — RESEND_API_KEY — is listed under that service; one it does not recognise is listed all the same. A name the runtime sets, like PORT, is never listed.

On the Overview

A preview's box says how much changed and how much of it is worth a look, beside its branch: feature · 3 changes · ⚠ 2 need attention. Inside the box, a card the pull request changed wears a chip — New for a service it began using or a component it added, Changed for one whose variables changed, Removed for one it stopped using — and a resource card says ⚠ 1 issue when something it reads is not configured here. The External services card counts the services with a name that needs attention, and each service behind it counts its own. These chips appear only inside a preview's box: they say what the pull request did, relative to its base.

Production and named environments get the same findings for their own commit — a variable a push began reading and nobody configured — without the chips, because there is no pull request to be relative to.

The panel

Select the preview's box to read the whole of it:

  • Ready, Needs attention or Analysing, with one line: Everything PR #42 reads is configured., 2 variables aren’t configured., or Some of what PR #42 reads is still being analysed.
  • Application changes, grouped as External services, Configuration and Architecture. Each row names what changed and who reads it — RESEND_API_KEY · Resend · referenced by web, PostgreSQL · Required by web — and where Kuppit saw it: Detected from: resend package, RESEND_API_KEY.
  • In PR #42: what each change means here. marks something worth attention, something worth knowing. A row reads Not configured for PR #42 · New in this pull request, or Configured in Production, or Also listed in .env.example; a resource's reads Nothing in PR #42 provides it.
  • No longer referenced: a name the pull request stopped reading that some environment still holds, each environment a link to its Variables. Nothing is deleted from here, or anywhere, on Kuppit's say-so.

Select a card instead to read only the rows about it.

A variable is referenced by a service, never required by it: process.env.X proves the code reads a name, not that the application cannot run without it. Only a resource — a database the code connects to — is Required by it.

Set variable

Set variable beside a finding opens the same form the Variables tab uses, beneath the finding, with the name filled in and still editable. It sets the variable on the preview's service, exactly as the Variables tab would. The finding disappears the moment it is saved, and the check on the pull request is written again.

Ready and needs attention

StateMeaning
ReadyEverything the commit reads is configured in this environment.
Needs attentionSomething the commit reads is not configured here: a name new in this pull request, or one Production has and the preview did not inherit. The deploy proceeds.

Nothing here blocks a deployment. Kuppit has identified something worth looking at, not decided that you must configure it; a name the code has always read without anyone setting it is listed for information, never as attention.

The check on the pull request carries the same account beneath its summary, and reads Deployed · needs attention while something is.

What is not decided for you

  • A name listed in .env.example that the pull request did not add is information, not attention: plenty of projects list optional variables there.
  • A preview without Production's database is a decision the preview recorded, so an unchanged requirement only informs; one the pull request introduced is worth attention.
  • A variable no longer referenced is never deleted. Kuppit knows the code stopped reading it, not that nothing else does.
Was this page helpful?