Setting up the CCC Discipleship Hub

For the person managing cccyouth.org. You will need about an hour, and no coding. There are three files: index.html (the hub), setup.sql (the database rules) and this guide.

What you are setting up

The hub is one web page (index.html). It stores its data in a Supabase project, a hosted database with sign-in, and the rules in setup.sql decide who may see or change what. For example, students cannot read attendance codes, change their own role, or see other families’ records, and the server checks the class code, not the page.

Steps

1. Create the project. Sign up at supabase.com, create a new project, choose a strong database password and save it. Pick a region near your users.
2. Load the rules. Open setup.sql in a text editor. Near the end, change YOUR-EMAIL@cccyouth.org to the email of the first supervisor. In Supabase, go to SQL Editor, paste the whole file and press Run. It should finish without errors.
3. Set the website address. Go to Authentication > URL Configuration. Set Site URL to the final address, for example https://hub.cccyouth.org, and add the same address under Redirect URLs.
4. Set up email sending (do this before launch). Supabase’s built-in email sender allows only a handful of sign-in emails per hour. Under Authentication > SMTP Settings, connect the church’s own email service, such as Google Workspace or a mail provider, so a whole cohort can sign in.
5. Copy the two keys. Go to Project Settings > API. Copy the Project URL and the anon public key. Open index.html, find the lines near the top of the script that say PASTE_PROJECT_URL_HERE and PASTE_ANON_PUBLIC_KEY_HERE, and paste the two values between the quotes.
   Only use the anon public key. Never paste the service_role key into the page.
6. Publish the page. Create the subdomain (for example hub) in your hosting or DNS panel, make sure it uses HTTPS, and upload index.html as its home page. Any ordinary web hosting works because the hub is a single static file.
7. First sign-in. The supervisor opens the address, enters the email from step 2 and follows the emailed link. They register and choose Supervisor, and are approved automatically. Everyone else registers themselves: students are approved at once, and staff roles wait for a supervisor to approve them in the People tab.

A five-minute check before inviting people

1. Register a test student and a test Team Lead from two different emails. Confirm the Lead stays pending until the supervisor approves.
2. As supervisor, open a check-in on Class 1. As the student, enter the code and confirm it is accepted, and that a wrong code is refused.
3. As the student, confirm there are no Programme or People tabs and no other students’ records.
4. As supervisor, create a family, assign the Lead and add the student, then check the Lead sees it.
5. Issue a certificate and download the PDF as the student.

When finished, delete the test accounts under Authentication > Users. Their records can be removed in the Table Editor (table docs, rows starting people/).

Good to know

• Adding more first-line supervisors: run insert into admins(email) values ('name@cccyouth.org'); in the SQL Editor, then they register as Supervisor. Later, any supervisor can approve other supervisors.
• Backups: export the docs table from the Table Editor after each cohort, or use the plan’s backup option. Check the current free-plan limits, including pausing of inactive projects, on Supabase’s pricing page.
• Privacy: the hub stores names, WhatsApp numbers and optional emails. Students can see names and numbers of staff and of students in their own family or project group only. Add a short privacy notice, and parental consent if any participant is under 18.
• Messages: WhatsApp and email notices open the sender’s own app with the message ready. They are not sent automatically.
• Edits at the same time: if two people change the same record in the same second, the last save wins. This is rare, and does not affect attendance.

What has and has not been tested

The database rules in setup.sql were run against a local PostgreSQL copy with more than fifty checks, covering role changes, attendance codes, who can read what, and the end of onboarding. The page logic was tested against a simulated backend. It has not yet been tested against a real Supabase project, real sign-in emails, or your hosting. Expect to fix a small thing or two in the first hour, and send any error message you see to whoever built this so it can be corrected.