Moreover it is required in stewards, that a man be found faithful.1 Corinthians 4:2, KJV
Somebody built your church’s website. In most small churches it was not a company; it was a member — a young man who was good with computers, a retired teacher, a deacon’s son-in-law — who gave the church a hundred hours nobody paid for. He registered the domain on his own card because it was quicker. He set up the hosting under his own email because the church did not have one. He made the admin password, and he is the only one who knows it, because nobody else ever asked.
Then his company moves him to Tennessee. Or he takes a church in another county. Or he gets sick, and for a year the website is the last thing on anyone’s mind, and then one Sunday the domain renewal notice goes to an inbox nobody checks, and the site goes dark. Nothing was hacked. Nothing failed. The church simply never wrote down where the keys were, and now the man who held them is gone — and the church, which owes him gratitude, is instead calling him about a password.
This entry is how to keep that from happening. It takes one afternoon, and it is the kindest thing you can do for the volunteer, because it lets him leave well.
Who this is for.
The pastor, the clerk, or a deacon — whoever will still be here in five years. Not the volunteer. He knows all of this already; the problem is that only he knows it. If your church runs FaithKit, one section near the end is specific to you. If it runs anything else, everything here still applies; the names of the keys change, the keys do not.
How a church actually loses its website.
Not all at once. It goes in stages, and each stage looks fine from the pew:
The four stages, in order
- The volunteer leaves on good terms. The site keeps working. Nobody notices anything, because nothing has changed yet.
- Something small needs changing — a service time, a new deacon’s name. Nobody can log in. The church lives with the wrong service time for a year. Visitors come at the wrong hour.
- A renewal notice goes to the wrong inbox. The domain or the hosting lapses. The site is gone; sometimes the domain is bought by a stranger within days.
- The church starts over. A new site, a new address, a new email. Ten years of Sunday recordings and every prayer-list entry are on a server nobody can reach. The old address on the sign out front now points at nothing.
Every stage was preventable at the first one. That is the whole argument for doing this now, while he is still here and still glad to help.
The five keys.
A church website hangs on exactly five things. Each is a key; each is held by somebody; and for each one the only question that matters is who else holds it.
Notice that the first two keys are different in kind from the rest. A lost admin password can be reset by someone who holds the host. A lost host login can be recovered by someone who holds the email it was opened with. But a domain registered in a departed member’s personal account is his, in the eyes of the registrar, and no amount of explaining that you are the church will change that. The registrar is right to refuse; that rule is what keeps strangers from taking your domain. It just means the domain has to be put right while he is still reachable.
The one-afternoon handover.
Do this with the volunteer, at a table, with the church computer and a printout of the five keys. It is not an audit and it should not feel like one; you are asking him to help the church keep what he built. Two hours, most of it waiting for confirmation emails.
With the volunteer, while he is still here
- Give the church an email address of its own if it does not have one —
office@yourchurch.org, or a plain mailbox the pastor and the clerk can both open. Every key below gets moved to this address. This is the single most important step; the rest are details. - Key 1 — the domain. Log in to the registrar together. Change the account email to the church’s address, put the church’s card on file for renewal, and add the pastor or clerk as a second contact if the registrar allows it. If the domain is inside the volunteer’s personal account among his other things, move it to an account the church opens — registrars call this a transfer or a “push” and it takes a few days. Do not let the renewal date pass while this is in motion; renew it first if it is close. (The order of operations is in No. 01.)
- Key 2 — the host. Same steps: account email to the church’s address, church’s card on file, second contact added. Write down the company, the renewal date, and what it costs.
- Key 3 — the admin login. Have him change it, at the table, to a new password that he does not keep. Write it in the church’s password book and put the book in the safe. Two officers know where the book is.
- Key 4 — the members key. Same. Change it, write it down, and decide who hands it out to new members from now on.
- Key 5 — the drive. Make this month’s backup together — the first-Monday routine from No. 05 — and let the officer do it with his own hands while the volunteer watches. Put the drive with the church’s records. Put the program zip on it too.
- Ask the two questions he will not think to answer. “Is there anything else on your card or your email that the church depends on?” (a mailing list, a video account, a map listing, a separate email service) and “Is there anything only you know how to do?” (how the sermons get posted, how the recordings get sliced). Write both answers down.
- Have him log out of everything on his own devices, and thank him. Not as a formality — see the last section.
If the volunteer is already gone.
Work the keys in order, because the first two decide whether the rest matter.
The recovery order
- Call him first, and kindly. Most volunteers who moved away will spend twenty minutes on the phone to hand things over properly — they built it; they want it to live. Ask for the afternoon handover above, done by phone and email over a week. Everything below is for when that is not possible.
- Find out who holds the domain. Any “whois” lookup will tell you the registrar and the renewal date, even when the owner’s name is hidden. If the renewal is close, this is urgent. If the domain is in his personal account and he cannot be reached, the registrar will generally not release it to you; a church can sometimes recover a domain after it lapses, but that is weeks of uncertainty and a stranger may buy it first. Decide early whether to wait for the old address or begin a new one, and if you begin a new one, put it in the church’s name from the first minute.
- Then the host. The host’s login is usually recoverable through the email the account was opened with. If that was his email, he has to help. If it was the church’s, use the forgot-password link and you are in. Once you hold the host, you hold the folder — and the folder is the church’s records, whatever happens to the logins.
- Download the whole folder before you touch anything. Prayer list, directory, sermons. Put it on a drive. Now nothing you do next can lose the records.
- Then the admin login. On most platforms, “forgot password” sends a reset link to the account email — which is why the domain and host came first. On FaithKit the way back in is different and honest; it is in the note at the end.
- Then the members key. Change it as soon as you can log in, and tell the members the new one on Sunday.
- Then write the sheet (next section) so this is the last time.
Put the keys in the church’s name.
The rule under all of this is simple: the church’s accounts belong to the church, the way the building does. The deed is not in the treasurer’s name because she signed the papers; it is in the church’s name and she is an officer. The domain, the host, and the email they are tied to should be the same — opened by an officer, on a church address, on the church’s card, with a second officer named as a contact.
This is not about trusting the volunteer less. It is about not asking him to carry something that was never his to carry. A man who builds the church a website out of love should not also have to remember, every January, that the church’s domain is quietly renewing on his own card. Taking that off him is a courtesy.
Hand the sheet forward.
No. 05 ended with “the one page to write down” — the domain, the host, the two logins, the backup, the second person, the zip. If you did the afternoon handover, that page now has two names under every line, and a church email at the top. It lives in the records drawer with the drive, and it is the thing that gets handed to the next volunteer on his first day — not a password over the phone, but a sheet that says what the church owns and where it is kept.
Read it at one business meeting a year, the way the treasurer reads the report. Thirty seconds. “The domain is registered at such-and-such, in the church’s name, renews in March, the clerk and I both have access; the backup drive is in the safe; last backup was the first of the month.” A church that can say that sentence out loud owns its website. A church that cannot is borrowing it from whoever happens to remember.
Thank them properly.
The volunteer who built your site gave the church something a company would have charged thousands for, and then kept it running for years, for free, mostly unnoticed, because a website that works is invisible. When he moves away, the handover is the church’s chance to notice. Say so from the pulpit. Put it in the bulletin. Let the last thing he hears about the website be gratitude, and let the keys he hands over be received as a gift kept, not a problem solved.
Two logins, one folder, and one thing we have not built yet.
A FaithKit site has exactly two passwords — the admin login and the shared members key — and both are set once, in the setup wizard, and stored scrambled in a small file called .env inside the site folder. Everything the church has typed or uploaded is in plain files beside it. That is most of what owning the site means, and it is why keys 1 and 2 matter more than 3 and 4: whoever holds the host holds the folder, and the folder is the church.
Here is the honest part. There is no “change the passwords” screen in the admin yet. Today, if the admin password has left with the volunteer, the way back in is to run the setup wizard again: copy the setup/ folder back up from the program zip, delete the small file config/.installed.lock on the server, and open /setup/ in a browser. It will ask for the church’s name and details and two new passwords, and it will write them fresh. Two cautions: it also rewrites the settings file (config/site-config.json) — so copy that file to the drive first and put your service times and colors back afterward — and it does not touch data/ or media/, so the prayer list, directory and sermons are safe. A proper password screen in the admin is on the list, and when it ships this note will get shorter. If MattCreates hosts the site for you, the domain still belongs in the church’s name and the folder is still yours — ask, and we hand it over.
The sample church at faithkit.org/demo is set up exactly this way; the sample is not a real congregation.