Skip to content
Go to console
Go to console

What the app keeps and never keeps

Every stack is in sync, and Penny rests on a calm quayEvery stack is in sync, and Penny rests on a calm quay

The app keeps a timeline, not a map of your infrastructure. It holds no cloud credential, it cannot deploy on its own, and GitHub stays the source of truth.

Facts at the level of a stack, read from what the action publishes: the dashboard’s markers, the deployment records and the workflow runs. See What Sluiceway writes for that shape.

  • Per stack: its stack id, its row state, how many resources it deletes or replaces, drift and resources gone outside the code, and whether its box is ticked.
  • Per deploy: the stack, who ticked or who merged, which commit, which run, how it ended, when, and whether it was an outside deploy.
  • Per tick in the app: who, which stack, when, and how it was judged, in one word.
  • Per scan: when it started, its commit, when its dashboard was written, and how many stacks it drew drifted.
  • Per merge, for Insights: the merge commit and when it was merged.
  • Per rescan asked in the app: who asked, when, and the run it started.
  • Per repo: why its onboarding pull request could not be opened, and why its first scan failed, each as one word from the app’s fixed list.
  • No resource name, property path, diff or value. Not in its database, not in its pages, not in the pull requests it opens. A row in the app shows counts, and the changes are on GitHub. When sluiceway preview asks for a stack’s changes, the app reads its preview page from GitHub at that moment, hands it on, and keeps none of it.
  • No text of a row, an issue title or a status description, and of a merged pull request nothing but its commit and time: no number, title, description, branch or author.
  • None of your repo’s files. For the onboarding pull request and to explain a failed first scan, the app reads a copy of the repo into a temporary directory and removes it when it is done, whether it worked or failed. The app refuses a copy larger than 100 MB.
  • No token of yours. Signing in reads who you are and which installations you may see, and the token is dropped. The app keeps no token of yours, so it cannot act as you.
  • No card, email, address, business name or tax id. Stripe keeps those. The app keeps your plan, what Stripe says about the subscription, when the period ends, and Stripe’s ids.
  • History: deploys, ticks, rescans and merges are kept for your plan’s history, which is 30 days on Free, 13 months on Team and 3 years on Team Plus. What is older is deleted each night.
  • The newest state of each stack is kept whatever its age: its last deploy, a deployment record that is still open, and the newest scan of its repo.
  • A plan that narrows, by falling back to Free or moving to a smaller plan, keeps its wider history for 30 days. A paid plan that starts again within them loses nothing. After them, what the new plan does not keep is deleted.
  • A repo taken out of the installation: its facts are kept for 30 days, then deleted.
  • An uninstalled app: everything of the installation is kept for 30 days, then deleted.
  • Delete everything, in the org’s Settings, deletes it all at once.
  • Backups: the database is backed up each night, and a backup is kept for up to 12 months. Deleted data leaves the backups as they age out.

After a deletion the app keeps the account’s name on GitHub and the date, to confirm the deletion when you ask.

The terms and the privacy policy say the same, with what is kept about a person: sessions, tokens and logs.

The app never holds, asks for or supplies a cloud or infrastructure credential. Your credentials stay in your runners, set up as Credentials and your own tooling describes. The app does not ask GitHub for permission to read your secrets, and the onboarding pull request names the secrets a stack needs without ever seeing one.

The app cannot deploy anything. Your runner does, as it does without the app.

  • A deploy starts from a person’s tick, on the dashboard or in the app, judged with the action’s own tick rule, the same code your workflow uses.
  • Only on a repo that names the app in recordWriters, a line of sluiceway.yaml that goes through review.
  • The app opens a record and starts your workflow. Your runner then previews the stack again and deploys only when the fresh preview gives the diff hash the person approved. A change that moved in between is refused.
  • A stack that deletes or replaces resources still waits for a person’s tick.

Nothing else the app does starts a deploy. A rescan runs a scan. Edit mode and the onboarding pull request are pull requests, and a person merges them.

The app is a view of what GitHub holds, and catches up with it.

  • Your workflow keeps working without the app. Installing the app changes nothing in it and turns nothing off. When you tick on the dashboard, your workflow judges and deploys the tick itself, whatever the app does. When both act on the same tick, whoever opens the deployment record first has it, and the other finds the record open and does nothing more.
  • When the app is down, nothing is lost. On every start it reads each repo again since the last point it saw: the dashboard, the deployment records and the workflow runs. GitHub sends the webhooks it missed again too. A downtime delays what the app shows and never loses it.
  • What the app shows follows GitHub. A dashboard written again, a record closed, a repo removed from the installation: the app brings its facts up to date. The facts of a repo the installation no longer covers are kept for 30 days, then deleted.

Uninstall it from GitHub’s settings for the installation. Your dashboards, your workflow and your deploys go on as before. Everything edit mode wrote is a documented key of sluiceway.yaml that the action reads on its own, so the dashboard looks the same. Take sluiceway[bot] out of recordWriters when you no longer want the app to open records.

The app keeps what it has of the installation for 30 days after the uninstall, then deletes it. To have it gone at once, use Delete everything, the last section of the org’s Settings tab, in place of uninstalling: an admin of the org, or the person whose account it is, confirms by typing the org’s name, the app deletes everything it keeps of the installation, and then uninstalls itself. While Stripe still charges a plan, it asks you to cancel the plan first.