Practical Reduction: Stop Paying, Regain Control

Audit your current cloud use

Step 1: List everything. Walk through every system your tribe runs:

• Email (Gmail, Outlook, hosted solution?)
• File storage (Google Drive, OneDrive, Dropbox?)
• Permitting system (SmartGov on cloud, or self-hosted?)
• Enrollment database (cloud-hosted? On-premise?)
• Financial management (Quickbooks Online, NetSuite?)
• Communications (Slack, Teams?)
• Video hosting or conferencing (Zoom, Google Meet?)
• Health records (if applicable)
• School systems (if applicable)
• Websites

Step 2: Calculate annual cost. Add up what you’re paying for each service. Include licensing fees, storage overage charges, and per-user costs. Example:

• Gmail (50 users at $6/month): $3,600/year
• Google Drive (2TB: $10/month): $120/year
• Slack (30 users at $8/month): $2,880/year
• SmartGov permitting (contract): $20,000/year
• Total cloud spending: ~$27,000/year (and this is conservative for most tribes)

Step 3: Understand who controls the data. For each service: Where does the data live geographically? Who owns it? What happens if the company changes terms? What’s the exit cost if you leave? Can you download everything, or are you locked in?

This is where you discover the problem. Your enrollment data lives on Microsoft servers. Your communications live on Slack’s infrastructure. You’re paying rent on land you don’t control, and the landlord can raise rent whenever they want.

Understand your actual data needs

What are you storing?

• Enrollment: text database, probably under 1GB per 1,000 members
• Permits: documents + metadata, maybe 100GB for 20 years of permits
• Health records: more substantial if you run health services, but still measurable (maybe 50GB–500GB depending on scale)
• Communications: email archives, maybe 50GB–200GB
• Personnel/governance: probably under 100GB
• Archives and historical documents: varies, but call it 1–20TB

Add it up. Most tribes need 5–50TB of storage. Even large tribes rarely exceed 100TB. To put that in perspective: a single external hard drive holds 20TB. A used server with 100TB is $5–10K.

What are you computing? Permitting systems process applications when submitted. Enrollment systems answer queries. Email moves messages. Financial systems run monthly reports. Health records retrieve patient files. None of this requires continuous, high-power compute. Peaks happen during business hours or at deadline times. Valleys are deep.

Peak compute needs for most tribes: 2–5 MW. Many tribal governments need under 1 MW baseline. To compare: a hyperscale center is 50–100+ MW continuous. A regional data center is 10–20 MW. A self-hosted server setup for a tribe is 50–200 kW.

What uptime do you actually need? Does enrollment need to be available 24/7 on weekends? No. Can permitting be down for scheduled maintenance on Sunday mornings? Yes. Does email need 99.99% uptime, or is 99% sufficient? (Hint: 99% means 3.6 days of downtime per year; 99.9% means 8.7 hours; most tribal systems don’t need 99.99%.) This matters because high-uptime infrastructure costs more and requires more complexity. Understanding your actual tolerance lets you right-size.

On-premise options

Self-hosted servers (the option most tribes should consider)

What it is: Servers you own, located in a physical space you control (tribal office, a server room, a closet), running open-source or commercial software, connected to the internet.

• Storage: 40–100TB for $5–15K upfront, depending on redundancy.
• Compute: 5–10 nodes (servers) for permitting, email, databases, file serving: $20–40K upfront.
• Cooling: Closed-loop system (no water evaporation): $2–5K.
• Power: UPS (backup power) to survive outages: $5–10K.
• Staffing: 1–2 people to manage it, backup/restore, updates, security.

Total upfront cost: $35–70K. That’s paying for about 3 years of your current cloud bills. After that, you own it. Annual costs: server replacement (spread over 5 years), power, internet, staffing — call it $30–50K/year including staff.

This is the right choice for most tribes. The cost is lower over 5 years, you maintain sovereignty, and the system scales to real tribal needs.

Hybrid approach (for larger tribes or risk-averse governments)

Keep some systems on cloud, move others to on-premise. Strategy: move everything that contains sensitive data (enrollment, health records, personnel) to on-premise. Keep non-critical systems on cloud (maybe a backup email, non-essential collaboration tools).

This gives you the security of on-premise infrastructure for what matters most, while reducing cloud dependency. Cost falls somewhere between full cloud and full self-hosted.

Specific tools: open-source and commercial

These run on your servers or on affordable hosted infrastructure, and they replace expensive cloud SaaS.

Email

Nextcloud Mail or self-hosted Mail-in-a-Box (open-source, on your server). Cost: $50–200/month for hosting if not self-hosted, or $0 if you run it yourself.

File storage

Nextcloud (open-source, on your server). Same cost structure as email.

Permitting

If you’re running SmartGov or another cloud permitting system, moving to a locally-managed instance (if available) or a simpler system like Odoo (open-source) can reduce cloud dependency. Requires more staffing to maintain.

Database/records

PostgreSQL or MariaDB (open-source databases). Enrollment, permits, financial records can all run on these with custom or off-the-shelf frontends.

Communication

Mattermost or Rocket.Chat (open-source, Slack alternative). Runs on your server. Cost: $0 software, $2–5K/year hosting or $0 if self-hosted.

Calendar/scheduling

Nextcloud Calendar (open-source, Outlook alternative).

Video conferencing

Jitsi Meet (open-source). Requires more bandwidth and server power, but doable.

Financial management

Odoo (open-source community version) or LedgerSMB (open-source). More complex than QuickBooks but fully controllable.

Getting help: you don’t have to build this alone

Full self-hosting isn’t an all-or-nothing, do-it-yourself proposition. Two paths reduce the burden on any single tribe while keeping data off hyperscale infrastructure: paying someone to set it up and run it, or pooling resources with other tribes.

Managed self-hosting providers

A managed provider builds and operates the servers for you — on hardware dedicated to your tribe, not shared multi-tenant cloud infrastructure — while your staff (or theirs, under contract) handles day-to-day operations. This gets you out of buying and racking hardware yourself while keeping the sovereignty benefit that actually matters: your data sits on infrastructure your tribe controls the terms of, not a hyperscale vendor’s.

What to look for before signing:

• Data residency and ownership terms in writing — where physically does the hardware sit, and who has access to it?
• No subcontracting to hyperscale cloud underneath the service. Ask directly: does any of our data ever touch AWS, Azure, or Google Cloud infrastructure as part of how you deliver this?
• Full data export and exit terms. If you leave, can you take everything with you in a usable format, and how fast?
• Staff training built into the contract, not withheld as a way to keep you dependent. The goal is to build tribal capacity, not swap one vendor lock-in for another.
• Preference for Indigenous-owned or Indigenous-led providers where they exist, and for firms with a track record working with tribal governments specifically — they’ll already understand the sovereignty stakes.
• Transparent, itemized pricing. Vague bundled quotes make it hard to know what you’re actually paying for or to compare against building it yourself.

Federated and cooperative models

Instead of one tribe building and staffing infrastructure alone, multiple tribes or Indigenous organizations can co-invest in shared servers, shared storage, and shared technical staff — splitting the cost of the capacity none of them individually need at hyperscale, while multiplying what they can afford together.

What this can look like in practice:

• A regional consortium of smaller tribes jointly funding and governing a shared data center, with capacity partitioned per member and costs split by usage or by agreement.
• Shared IT staff serving multiple tribal governments under an interlocal or intertribal agreement, the way some tribes already share other specialized staff (legal, engineering) that no single nation can justify hiring alone.
• A larger, more technically capable tribe hosting infrastructure for smaller neighboring nations under clear governance and data-separation terms, rather than any of them defaulting to commercial cloud.

The advantage over a single-tribe build: the staffing and hardware costs that make solo self-hosting expensive get divided across multiple governments, while the sovereignty benefit — data staying on Indigenous-controlled infrastructure — holds for everyone involved. The tradeoff is governance complexity: shared infrastructure needs clear agreements up front about data separation, decision-making authority, and what happens if one partner wants to leave.

If no existing consortium serves your region, this is worth raising with neighboring tribes or your regional intertribal organization directly — the same conversation that produces shared health or legal services can produce shared infrastructure.

Data minimization

Before you build anything, ask: do you need to store this? Many cloud costs come from hoarding data. “Just in case” archives, old email, redundant backups of backups.

Minimization questions:

• Email: do you need to keep email older than 5 years? Set a deletion policy. 5-year retention probably reduces storage by 50%.
• Permits: do you need images and PDF files, or just the decision? Raw documents can be archived (rarely accessed) separately from active records.
• User files: clean out inactive accounts quarterly. Employees who leave shouldn’t have cloud storage forever.
• Logs: do you need to keep server logs older than 6 months? 1 year? This is mostly for compliance. If your requirements are lower, delete them.
• Drafts: ephemeral files don’t need backup or long-term storage.

Aggressive minimization can cut your storage need by 30–50%, which means cheaper hardware.

Building internal capacity

Moving to self-hosted requires staffing. This is a feature, not a bug.

You’re building technological capacity inside the tribe. Someone learns how to manage servers, patch security updates, handle backups, troubleshoot outages. That’s tribal knowledge. It doesn’t leave.

Hiring paths:

1. Hire for potential, train for skill. Look for people interested in technology who understand tribal systems. Pair them with online learning (Linux Academy, Pluralsight, YouTube) and with mentors in other tribal governments or nonprofits running similar systems.
2. Partner with another tribe or Indigenous organization that’s already managing self-hosted systems. Do knowledge exchange. Learn from their mistakes.
3. Hire contractors for setup, manage locally for operations. Get help building the initial infrastructure, then keep internal staff managing it. Cheaper than ongoing contractor costs, builds ownership.
4. Start with 1–2 systems. Move email and file storage first (lower complexity, high impact on vendor reduction). Then tackle permitting or health records. Don’t do everything at once.

Migration checklist

Phase 1: Plan (month 1)

• Audit current systems and spending
• Calculate your actual data needs
• Define uptime requirements
• Choose initial systems to migrate (start with 2–3)
• Get budget approval from leadership
• Hire or designate staff responsible for managing new systems

Phase 2: Build (months 2–4)

• Source hardware
• Set up physical space (climate-controlled room or closet)
• Install and configure servers
• Set up networking and backups
• Install and test software for first batch of systems
• Train internal staff on basic operations

Phase 3: Migrate (months 4–6)

• Export data from cloud
• Import to new systems
• Run parallel testing (both systems active, comparing)
• Cutover to new system (turn off cloud version)
• Monitor closely first 2–4 weeks
• Plan decommissioning of cloud service

Phase 4: Operate (ongoing)

• Daily: backups, monitoring, user support
• Weekly: security patches, system health checks
• Monthly: capacity planning, performance review
• Quarterly: staff training, process improvements
• Annually: hardware refresh planning, cost review

What you’re not paying for anymore

After 5 years of self-hosted systems, calculate what you’ve stopped paying:

• No cloud vendor rate increases
• No lock-in costs to leave a service
• No surprise overage charges
• No dependency on corporate whims or bankruptcy
• No data living on servers you don’t control

You’ve also built:

• Technical staff who can hire and mentor others
• Institutional knowledge about your own systems
• The ability to modify or customize software
• Disaster recovery that doesn’t depend on a company’s data center
• Resilience from diversifying away from single vendors

← Back to Indigenous AI Commons