Host a Library

Worship Assist can run on your own cloud storage instead of a shared server. You create a private storage bucket, hand the app one access key, and the app does the rest — you build your song library inside the app and share it with your team by link. Nothing is public; you own the storage and the content.

The app speaks the S3 API, so it works with Amazon S3 and Backblaze B2 (and other S3-compatible stores). This guide covers S3 and B2 in full.

This is the source for the published setup page the app links to: https://pmarch502.github.io/good-faith-studio/worship-assist/host/

The big picture

1. Create a private bucket — on Amazon S3 or Backblaze B2.
2. Create one access key for that bucket (full access).
3. In the app: Connect a library → Host a library, enter your bucket + key, and Connect. You're now the host.
4. Add your songs in the app — Add songs → Publish. You never upload files by hand; the app converts and stores them for you.
5. Share your library — the app gives you two links from that one key. Send the User link to your team.

Only steps 1–2 happen outside the app, and only once.

One key, two links — how access works

You make a single access key. When you enter it in the app, the app produces two shareable links from it:

• Host link — can do everything: publish songs, manage the library, plus all the arranging and mixing. Keep this for yourself (and any co-hosts).
• User link — everything except publishing songs and managing the library. This is the one you give team members. They can play, and build arrangements, mute sets, set lists, and mashups — they just can't upload or manage the songs.

Both links point at the same bucket with the same key. The difference is enforced by the app — a User link simply doesn't show the publish/manage tools.

Treat the links like passwords. The access key is carried inside the link (lightly scrambled, not encrypted), so anyone you send a link to effectively holds the key. Share links only within your team. This is the right level of protection for a trusted group; it isn't meant for posting a link publicly. Two good habits:

• Turn on bucket versioning (below) so any accidental change or deletion is recoverable.
• If a link ever leaks outside your team, delete the key and create a new one, then re-enter it in the app — you'll get fresh links and the old ones stop working.

What the app will ask for

When you connect, the app asks for these (you get them from the provider setup below):

Field	What it is
Provider	Amazon S3 or Backblaze B2 (pick from the list)
Region	your bucket's region code — the app builds the endpoint from it
Bucket	your bucket name
Access key ID	the public half of your key
Secret access key	the private half — shown once, so save it
Library name (optional)	a friendly label, e.g. "Grace Worship"
Folder / prefix (optional)	leave blank unless you want the library under a subfolder

Amazon S3

1. Create the bucket

1. S3 console → Create bucket.
2. Bucket name: globally unique (e.g. grace-worship-library).
3. Region: pick one near your team and note its code (e.g. us-east-2).
4. Block Public Access: leave ON (fully blocked). The app uses your key, not public access.
5. Create.

2. Turn on versioning (your safety net)

Bucket → Properties → Bucket Versioning → Edit → Enable → Save. Now every overwrite and delete is recoverable.

3. Create one access key

1. IAM console → Users → Create user (e.g. worship-app, no console sign-in needed).
2. Permissions → Attach policies directly → Create inline policy → JSON, and paste the policy below (replace grace-worship-library with your bucket name).
3. Finish creating the user, then open it → Security credentials → Create access key → Application running outside AWS → copy the Access key ID and secret now (the secret is shown only once).

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ListTheLibrary",
      "Effect": "Allow",
      "Action": "s3:ListBucket",
      "Resource": "arn:aws:s3:::grace-worship-library"
    },
    {
      "Sid": "ReadWriteObjects",
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:PutObject", "s3:DeleteObject"],
      "Resource": "arn:aws:s3:::grace-worship-library/*"
    }
  ]
}

(Using a prefix? Change the second Resource to arn:aws:s3:::grace-worship-library/your-prefix/*.)

4. Values for the app

Field	Value
Provider	Amazon S3
Region	your bucket's region (e.g. us-east-2)
Bucket	your bucket name
Access key ID / Secret	from step 3

Backblaze B2

B2 exposes an S3-compatible API, so the same app works. The differences: B2's console, and it keeps file versions by default (no versioning switch to flip).

1. Create the bucket

1. B2 console → Buckets → Create a Bucket.
2. Bucket unique name (e.g. grace-worship-library).
3. Files in Bucket are: Private.
4. Create.

2. Find the endpoint + region

On the bucket's page, B2 shows an Endpoint like s3.us-west-004.backblazeb2.com. The region is the middle segment — here, us-west-004. That's what the app wants.

3. Create one application key

1. App Keys → Add a New Application Key.
2. Name it (e.g. worship-app).
3. Allow access to Bucket: restrict it to your bucket.
4. Type of Access: Read and Write (this includes delete).
5. Create — B2 shows the keyID and applicationKey once. Copy both.

4. Values for the app

Field	Value
Provider	Backblaze B2
Region	the endpoint's middle segment (e.g. us-west-004)
Bucket	your bucket name
Access key ID	the B2 keyID
Secret access key	the B2 applicationKey

B2's free tier includes 10 GB of storage — enough to try a few songs, not a full library.

In the app (once you have the values)

Connect as host

1. Open Worship Assist. On Connect a library, tap Host a library.
2. Pick your Provider, then enter Region, Bucket, Access key ID, Secret (the app fills in the endpoint).
3. Your Host and User links appear. Tap Connect to this library — you're now hosting.

Add your songs

Use Add songs → Publish in the app (host only, on a computer). Pick your stems; the app converts and uploads them into your bucket. You never touch storage folders by hand.

Adding a MIDI part

If you have the notes for a part as a .mid file, add it in the app: ? → Manage library songs…, click the song, then Add stems… and pick the file. Name it after the part — Piano.mid beside Piano.mp3. It then shows up in Add track for everyone, like any other part. You never put it in storage by hand.

It needs to line up with the audio you published: same tempo, same measures, and the same count-in if the audio has one. It doesn't have to run to the end of the song — a part that drops out early is normal. If it starts a bar or two early or late, you can drag it into place on the song's Edit Sections and Tempo/Time Sig Changes… screen. The app's User Guide (For Hosts → Adding a MIDI part) has the details.

Invite your team

On the Host a library screen, copy the User link and send it to your team (text, email, group chat). Each person pastes it into their own Connect a library screen — and they're in, with the play and arranging tools but not publishing. Keep the Host link for yourself or a co-host.

Other S3-compatible providers

The app works with any S3-compatible object store. In the app, choose Other (S3-compatible) and supply the endpoint + region yourself. The setup pattern is always the same: a private bucket + one full-access key scoped to it.

Provider	Endpoint pattern	Region example
Cloudflare R2	<account-id>.r2.cloudflarestorage.com	auto
Wasabi	s3.<region>.wasabisys.com	us-east-1
DigitalOcean Spaces	<region>.digitaloceanspaces.com	nyc3
MinIO (self-hosted)	your server host	often us-east-1

(Amazon S3 and Backblaze B2 are the two we've set up and tested.)

Checklist

• ☐ Bucket created, private
• ☐ Versioning on (S3) / it's the default (B2)
• ☐ One full-access key created; secret saved
• ☐ Connected in the app as host
• ☐ Songs added via Add songs → Publish
• ☐ User link shared with the team; Host link kept for yourself