Deploy and Protect

Put the app on a real address and set up the basics: a private place for secret credentials, access rules for your data, a way to see errors and a way to roll back. Use dummy data until the access rules are in place. Don't commit secret credentials to a repository.

Before you share the link

• Secret credentials live on the server or in your host's secret store. Browser code and browser-exposed environment variables are public.
• Some services give you publishable keys meant for the browser. Use them only with the service's access controls turned on and tested.
• Records have rules for who can read, create, update and delete them, tested as a signed-out visitor, user A, user B and a user from another organization. Hiding a button isn't access control.
• You can see errors when something fails, and you know how to roll back.

Worked example

Sam keeps secret credentials on the server and writes access rules so each user can read and edit only their own household's chores. He tests them as a signed-out visitor, user A, user B and a user from another household. One test fails: a signed-out visitor can read chores. He fixes the rule and reruns all four tests. Then he shares the link.

Common mistakes

• Committing secret credentials to a repository.
• Leaving the database open to anyone.
• No tested way to roll back.

Exercise

Go through the four-point checklist with dummy data. Record pass or fail for each item, including the four access tests, and fix anything that fails before sharing.