Remote Work in Alaska: Challenges and Hacks for Reliable Internet

The first time my internet went out during a production incident, I was standing on my porch at 2 AM in negative thirty degrees, brushing snow off a satellite dish with a broom. My team was in a Slack huddle trying to restore a database cluster, and I was in Caswell Lakes, Alaska, fighting physics.

That was three years ago. I've been working remotely from a cabin in the Mat-Su Valley ever since, and I've learned more about internet reliability than any network engineer ever wanted to teach me. This is the unfiltered version of what remote work from rural Alaska actually looks like — the failures, the workarounds, and the systems I've built to keep shipping code from a place where moose outnumber routers.

---

Why Alaska, and Why It Matters

I moved to Alaska because I was burned out, my wife and I wanted a slower pace of life, and property near Caswell Lakes was something we could actually afford. I'd spent decades in offices and cubicles in the lower 48, and remote work meant I could finally live somewhere that didn't feel like a suburb of a suburb.

What I didn't fully appreciate before moving was how much of the modern remote work playbook assumes you have reliable, high-bandwidth internet. Every tool, every workflow, every "async-first" company culture still fundamentally expects that you can jump on a video call when things get serious. That assumption breaks fast when your nearest fiber line is forty miles away.

The Mat-Su Valley is not the bush. I'm not in Bethel or Barrow. I can drive to a Walmart in about forty-five minutes. But the internet infrastructure here is still limited compared to what you get in any medium-sized city in the continental US. Understanding that gap — and building systems around it — is what makes remote work from places like this sustainable.

---

The Internet Landscape in Rural Alaska

Let me lay out the actual options, because people often ask "can't you just get Starlink?" as if that solves everything.

GCI Fixed Wireless: This was my first option. GCI is the dominant ISP in most of Alaska, and in areas without cable or fiber, they offer fixed wireless. The speeds they advertise and the speeds you get are different conversations. I was getting 10-25 Mbps down on a good day, with latency around 60-100ms. On a bad day — which in winter was most days — it dropped to 2-5 Mbps with packet loss that made video calls sound like you were talking through a tin can.

Starlink: I got on the waitlist in 2021 and received my dish in early 2023. It changed my life, genuinely. Speeds range from 50-200 Mbps down, latency usually sits around 25-50ms, and it works in weather conditions that would make a traditional satellite provider laugh. But it's not perfect. More on that in a minute.

Hughes/Viasat: Traditional satellite. I had HughesNet briefly as a backup. The latency — 600ms or more — makes it functionally unusable for anything interactive. Fine for email. Terrible for SSH sessions, video calls, or anything involving real-time collaboration. I canceled it after two months.

Cell Hotspot: AT&T has limited coverage in my area. I keep a phone with a hotspot plan as a last-resort backup. It works for Slack messages and pushing a commit. It does not work for screen sharing or uploading a 200MB deployment artifact.

My current setup is Starlink as primary, GCI fixed wireless as secondary, and the cell hotspot as emergency tertiary. Three internet connections for one remote worker. Welcome to Alaska.

---

The Real Problems Nobody Talks About

The bandwidth numbers are one thing. The actual problems you hit daily are different.

Power Outages

Alaska has storms. Real storms. The kind that knock out power for hours or days. My area averages maybe six to eight significant outages per year, some lasting a few hours, some lasting over a day.

Remote work requires electricity. Not just for your computer — for your modem, your router, your Starlink dish (which draws about 50-75 watts continuously), and whatever display setup you use.

I run a battery backup (APC 1500VA UPS) on my networking gear and primary workstation. That gives me roughly 45 minutes on battery if the power goes out. For longer outages, I have a Honda EU2200i generator that I can run outside to keep the essentials going. The generator burns about a gallon of gas every four hours, so I keep twenty gallons on hand.

This sounds extreme until the power goes out during a sprint demo and you need to stay online for the next thirty minutes.

Cold Weather Equipment Failures

Electronics don't love negative forty. My Starlink dish has a built-in heater for snow melt, which works well, but the cable run from the dish to my router goes through an exterior wall, and I've had the Ethernet cable become brittle and crack in extreme cold. I now run the cable through conduit with foam insulation around it.

The GCI fixed wireless antenna is mounted on a pole on my roof. Ice buildup on the antenna degrades the signal significantly. I've had to climb up there with a heat gun more times than I care to admit. My solution was to install a small heated enclosure around the antenna base, powered by a thermostat that kicks on below zero.

Starlink Obstructions

Starlink needs a clear view of the sky. I'm surrounded by spruce trees. When I first set up the dish, I was getting two to three minutes of obstruction per hour, which doesn't sound bad until you realize that each obstruction event drops your connection for 5-15 seconds. If you're on a video call, that's a freeze. If you're in the middle of an SSH session, that's a disconnect. If you're deploying, that's a failed upload.

I ended up mounting the dish on a thirty-foot pole that a local welder fabricated for me. That got me above the tree line and dropped obstructions to about 15 seconds per 12 hours. Worth every penny.

---

The Systems I've Built Around Unreliable Connections

Knowing the connection will fail, the question becomes: how do you build your workflow so that failures don't destroy your productivity?

Automatic Failover

I use a TP-Link ER605 multi-WAN router configured for automatic failover. Starlink is the primary WAN, GCI is the secondary. If Starlink drops, the router switches to GCI within about ten seconds. The switch back happens automatically when Starlink recovers.

This doesn't help with active TCP connections — a video call will still drop during the switch — but it means that within seconds, I'm back online on the secondary connection without touching anything.

Local Development First

I never develop against remote services if I can avoid it. My local development environment has local instances of everything — PostgreSQL running locally, MongoDB locally, mock APIs for external services, local file storage instead of S3.

// config.js - environment-aware configuration
var config = {
    database: process.env.NODE_ENV === 'production'
        ? process.env.DATABASE_URL
        : 'postgresql://localhost:5432/myapp_dev',
    fileStorage: process.env.NODE_ENV === 'production'
        ? { provider: 's3', bucket: process.env.S3_BUCKET }
        : { provider: 'local', path: './uploads' },
    apiMocks: process.env.NODE_ENV !== 'production'
};

module.exports = config;

This means I can write and test code for hours without any internet connection at all. The only time I need a connection is to pull/push to git, deploy, or communicate with my team.

Git Workflow for Intermittent Connections

I commit early, commit often, and push whenever I have a stable connection. My habit is to push after every meaningful commit rather than batching pushes, because I never know when the next outage is coming.

I also keep a simple script that watches for connectivity and pushes pending commits automatically:

#!/bin/bash
# push-when-online.sh
# Watches for connectivity and pushes any unpushed commits

while true; do
    if ping -c 1 github.com > /dev/null 2>&1; then
        UNPUSHED=$(git log origin/main..HEAD --oneline 2>/dev/null | wc -l)
        if [ "$UNPUSHED" -gt 0 ]; then
            echo "$(date): Pushing $UNPUSHED commits..."
            git push origin main
        fi
    fi
    sleep 60
done

It's crude, but it works. I run it in a tmux session and forget about it.

Asynchronous Communication by Default

I made a deliberate decision early on to bias heavily toward asynchronous communication. This isn't just a preference — it's a survival strategy.

Video calls are the most connection-sensitive activity in remote work. A 3 Mbps connection that's fine for coding and Slack will make you look and sound terrible on Zoom. I ask teams I work with to default to written communication and reserve video calls for situations where face-to-face interaction genuinely adds value.

When I do need to be on a video call, I follow a checklist:

1. Camera off unless absolutely necessary (saves 2-3 Mbps)
2. Close all other bandwidth-consuming applications
3. Have my phone ready as a backup connection
4. Pre-load any documents I'll need to reference so I'm not downloading during the call
5. Use the Zoom or Meet chat as a backup channel if audio drops

I've been in meetings where my audio cut out for thirty seconds, and I typed what I was saying into the chat. It's not elegant, but it keeps the meeting moving.

---

Tools That Work Well on Bad Connections

Not all tools are created equal when your bandwidth is limited and your latency is high.

Things that work great:

• Terminal-based editors (Vim, Nano) over SSH — low bandwidth, tolerant of latency
• Slack — text-based, handles disconnections gracefully, syncs when you're back
• GitHub — web interface works fine on slow connections, CLI tools even better
• VS Code with local files — the editor itself is local, only extensions need network

Things that work poorly:

• Google Docs with multiple collaborators — constant sync traffic
• Figma — heavy real-time rendering
• Cloud-based IDEs (Codespaces, Cloud9) — your entire development experience depends on your connection
• Large file transfers without resume support

Things I switched because of connectivity:

• Moved from Google Docs to local Markdown files synced via git
• Moved from Jira to Linear (Linear's offline mode is genuinely good)
• Moved from cloud-based CI/CD dashboards to CLI-based status checks

# Check CI status without opening a browser
gh run list --limit 5
gh run view 12345 --log

---

The Seasonal Reality

Alaska has seasons that affect your internet in ways that no amount of planning eliminates entirely.

Winter (October-March): Shorter days mean more aurora activity, which can affect satellite signals including Starlink. Heavy snowfall requires regular dish clearing if you don't have the heated dish (I do, but ice storms still cause issues). Power outages are more frequent. The cold itself degrades equipment over time.

Breakup (April-May): This is Alaska's mud season. The freeze-thaw cycle can shift antenna poles, crack cable runs, and generally make outdoor equipment maintenance miserable. It's also when bears wake up, which makes climbing a ladder to service your antenna more exciting than it should be.

Summer (June-August): The best season for connectivity. Long days, mild weather, minimal precipitation. This is when I do maintenance on all my outdoor equipment — replace cables, check connections, tighten mounts, clear any vegetation that's grown toward my Starlink dish's field of view.

Fall (September): Everything works. It's beautiful. Enjoy it while it lasts.

---

What I'd Tell Someone Considering This

If you're a software engineer thinking about moving somewhere rural — whether it's Alaska, rural Montana, the Maine woods, or wherever — here's my honest assessment.

It's absolutely doable. I've been shipping production code, running two businesses, and maintaining open source projects from a cabin in Alaska for years. The work gets done.

It costs more than you think. My internet infrastructure — Starlink, GCI, router, UPS, generator, pole mount, heated enclosure, cabling — represents about $3,000 in upfront investment and roughly $200/month in service costs. In a city, I'd pay $60/month for gigabit fiber and be done with it.

You need redundancy in everything. One internet connection is not enough. One power source is not enough. One communication method is not enough. Build redundancy into every system that your work depends on.

Your team needs to know. Be transparent with the people you work with about your connectivity situation. Most teams are understanding if you're upfront about it. They're less understanding if you just randomly drop off calls without explanation.

You will adapt. The first six months were rough. I was constantly anxious about outages, constantly checking my connection speed, constantly apologizing on calls. Now it's just part of life. The systems I've built handle most failures automatically, and the ones they don't handle are rare enough that I deal with them as they come.

---

The Part Nobody Asks About

Everyone asks about the internet. Nobody asks about the part that actually matters — what it's like to step away from your desk, walk outside, and see the Alaska Range. To take a break from debugging a production issue by watching a moose walk through your yard. To end your workday when the northern lights start.

The internet challenges are real, and I've spent thousands of dollars and hundreds of hours solving them. But they're engineering problems, and engineers solve problems. The thing you can't engineer is the quality of life on the other side of those problems.

I write code from a cabin in Alaska. The internet goes out sometimes. I've built systems to handle it. And I'm not moving back.

---

Shane Larson is a software engineer, author, and the founder of Grizzly Peak Software. He writes code from a cabin in Caswell Lakes, Alaska, where his three internet connections mostly cooperate. Learn more at grizzlypeaksoftware.com.