TLDR
Fast advance and glacier solve the Corp’s scoring problem in different ways. Fast advance tries to shorten the interval between revealing an agenda and scoring it. Glacier spends more cards, credits, and time building a remote server the Runner cannot profitably challenge. Neither plan is inherently better. Choose the one your identity, agenda suite, economy, and legal card pool can support consistently.
The useful way to compare Netrunner fast advance vs glacier is not “speed versus defense.” It is scoring-window compression versus sustained remote control. A fast-advance deck still needs defense, especially on central servers. A glacier deck still benefits from tools that reduce how long an agenda remains exposed. If the larger Corp-versus-Runner structure is unfamiliar, start with what each side is trying to accomplish.
Start with the actual scoring rules
Fast advance and glacier are community strategy labels, not categories defined by the Comprehensive Rules. The rules provide the common baseline: the Corp may score an agenda when it has advancement counters at least equal to its advancement requirement. Scoring costs no click, is not an action, and is not compulsory merely because the requirement has been met. The Corp can therefore wait when another timing or information consideration makes waiting useful. The current Netrunner Comprehensive Rules provide the authoritative wording.
Agendas may always be advanced. A different installed card can be advanced only when its card text permits that. There is no general one-advancement-per-turn limit on an eligible card, although clicks, credits, timing, and card abilities constrain what the Corp can accomplish. When card text directly contradicts a general rule, the card text takes precedence.
That distinction matters because “fast advance” does not create a separate scoring rule. It describes a deck using legal card abilities and resources to satisfy an agenda’s advancement requirement within a compressed window. Likewise, glacier is not granted stronger servers by the rules. It is an architectural choice: the Corp invests enough in a remote that installing and advancing an agenda there becomes credible.
Netrunner fast advance vs glacier at a glance
| Deckbuilding question | Fast advance tendency | Glacier tendency |
|---|---|---|
| How does the Corp create a scoring window? | Compresses the time or actions needed to score | Makes a remote expensive or dangerous to contest |
| Where does the deck invest? | Scoring enablers, consistency, economy, and central defense | ICE, sustainable economy, remote support, and server development |
| What does the Runner try to disrupt? | The Corp’s hand, enablers, credits, and timing | The remote’s economic sustainability and defensive structure |
| Common failure | Drawing agendas without the resources or tools to score them | Building an expensive remote that the Runner can still solve |
| Typical information pressure | The Runner must identify when a score can appear | The Runner must decide whether each remote challenge is worth its cost |
Fast advance is a consistency problem
A fast-advance deck wants to reduce the Runner’s opportunity to interact with an installed agenda before it scores. That does not necessarily mean every agenda can move directly from HQ to the score area in one turn. The exact line depends on agenda requirements, legal card text, available clicks, credits, counters, and timing. The strategic objective is simply to make the vulnerable interval shorter and less predictable.
The deck therefore needs more than a few exciting scoring cards. It needs a repeatable chain: find an agenda, find the appropriate enabler, afford the complete sequence, and survive until the scoring turn. Draw without economy produces an impressive hand that cannot act. Economy without sufficient agenda access or scoring support produces time but no points. Enablers without compatible agendas create dead combinations.
Fast advance also shifts defensive pressure toward central servers. If the deck does not intend to build a dominant remote, the Runner may attack HQ to steal agendas before they score, R&D to exploit a slow draw, or Archives when the Corp discards under pressure. Central ICE is therefore not an optional afterthought. Its job is often to make repeated access consume enough clicks and credits for the Corp’s compressed scoring plan to come online.
Economy should be evaluated against complete scoring turns rather than individual card costs. Ask what credit total is required to install, advance, trigger relevant abilities, and still represent defensive rezzes. A deck that can technically assemble its combo but becomes unable to protect HQ afterward has converted points into a dangerous tempo loss. The broader principles in building a functional Netrunner economy package are especially relevant here.
Common fast-advance construction errors
- Too many specialized enablers and not enough draw or filtering to assemble the right pieces.
- An agenda suite whose advancement requirements do not align with the deck’s available compression tools.
- Treating central defense as wasted space because the deck does not plan to score in a remote.
- Counting gross income without calculating the credits needed for the entire scoring sequence.
- Assuming every agenda must use the fast-advance line, leaving the deck without a fallback when an enabler is unavailable.
Glacier is an infrastructure problem
A glacier deck creates a remote server that can support repeated scoring attempts. The important word is support. Installing several expensive pieces of ICE does not automatically produce a secure server. The Corp must be able to rez that ICE, preserve enough economy to threaten later layers, and continue advancing its board after the Runner reveals an efficient route through it.
A credible remote asks the Runner an uncomfortable question: is paying to enter this server worth the accesses, information, or disruption it provides? The answer depends on more than raw ICE strength. Different encounter effects, subroutines, rez costs, and vulnerabilities shape how the Runner approaches the server. Understanding how ICE and icebreakers interact helps explain why a layered server is an economic system rather than a wall made from isolated cards.
Glacier economy must be sustainable. A single burst of credits may rez the outer ICE once, but the deck also needs to advance agendas, replace trashed support cards, defend central servers, and recover after a contested run. If every remote challenge drains the Corp more heavily than the Runner, the server is only postponing failure.
The remote also needs a purpose before it becomes perfect. New builders sometimes delay scoring while adding one more ICE, one more upgrade, or one more economic card. That gives the Runner time to draw breakers and accumulate credits. The correct question is not whether the remote is impenetrable. It is whether the Runner can challenge it profitably now, given both players’ visible resources and likely hidden options.
Common glacier construction errors
- Choosing ICE for isolated power rather than considering rez costs and how the layers work together.
- Spending so much on the remote that HQ and R&D become efficient targets.
- Including defensive upgrades without enough economy or agenda pressure to make them matter.
- Waiting for a perfect server when the current board already offers a reasonable scoring window.
- Building only one scoring route, so the deck stalls when the Runner finds an efficient answer to the remote.
The Runner experiences two different kinds of pressure
Against fast advance, the Runner is often racing information. Runs on HQ can reveal whether agendas are accumulating, while pressure on R&D can punish a Corp that needs time to assemble scoring pieces. Even an unsuccessful run may expose ICE, force a rez, or reduce the Corp’s credit total enough to delay the next scoring turn. For more on why those outcomes matter, see how runs create information and access pressure.
Against glacier, the Runner is usually solving a repeated economic question. How much does the remote cost to enter now? What will it cost after another ICE is installed? Is the facedown card likely to be an agenda, an upgrade, or a bluff? Can pressure elsewhere force the Corp to spend the credits reserved for the remote? Glacier wins not merely when a run fails, but when contesting the server consumes enough tempo to open a scoring window.
Never-advance and hybrid plans break the false binary
Never-advance is another strategic label rather than a special rule. In broad terms, it describes installing a card in a remote without immediately placing advancement counters on it, preserving uncertainty about whether it is an agenda, asset, upgrade, or other eligible card. The value comes from hidden information: the Runner must decide whether checking the server is worth the tempo.
This can overlap with either major plan. A glacier deck can use facedown installs to make the Runner test its expensive remote. A deck with scoring compression can install early, invite the Runner to dismiss the card, and complete the score later if its legal tools allow. The important deckbuilding question is whether the bluff and scoring lines use compatible cards and resources—not whether the list fits one pure archetype label.
Hybrid plans are often sensible because the game does not guarantee the same board state every match. A defended remote gives a fast-advance deck somewhere to score when its enablers do not appear. Limited scoring compression helps glacier convert a narrow opening into points before the Runner fully solves the remote. The cost is dilution: every backup plan occupies slots that could improve the primary one.
Build from the agenda suite outward
The agenda suite determines what the deck must accomplish, so examine it before filling the remaining slots. For each agenda, ask how long it is expected to remain installed, what resources its scoring line requires, and whether the deck has a realistic alternative when the preferred route is unavailable. Avoid assuming that an agenda is suitable merely because it appears in an older list; legality and surrounding support can change by format.
Then audit the rest of the deck as a connected system:
- Identity: What recurring economic, informational, or scoring advantage does it contribute?
- Agenda suite: Do the advancement requirements and point values fit the intended scoring windows?
- Economy: Can the deck pay for a complete scoring turn or a prolonged remote contest?
- Draw and consistency: How reliably does it find agendas, ICE, economy, and scoring support in the needed order?
- ICE: Which servers require early protection, and which ICE remains useful after breakers appear?
- Remote support: Does each upgrade or defensive tool materially improve a scoring attempt?
- Central defense: What prevents the Runner from ignoring the remote and repeatedly attacking HQ or R&D?
- Flex slots: Are matchup cards solving demonstrated problems, or merely reducing the consistency of the main plan?
Faction tendencies may suggest a direction, but they do not replace this audit. An identity is useful when its ability supports the deck’s actual resource loop. For a broader orientation, compare the Corp factions and their characteristic tools without treating those tendencies as fixed classes.
Test the failure, not just the final score
After each game, record why the Corp could not score. “The deck lost” is too broad to guide a revision. A more useful diagnosis identifies the missing resource or broken link in the plan.
- No money: the line existed, but the deck could not pay for scoring and defense.
- No agenda: the deck stabilized without finding points, suggesting a draw or tempo issue.
- No enabler: the fast-advance line depended too heavily on a narrow combination.
- Unsafe centrals: the Runner gained too much access while the Corp prepared its plan.
- Remote failure: the Runner crossed the server too efficiently or forced unfavorable rezzes.
- Wrong timing: the Corp had the necessary cards but spent clicks or credits before the scoring window.
- Plan dilution: backup tools appeared more often than the cards required for the primary strategy.
Change only a few slots at a time. If economy is the diagnosed problem, replacing several ICE and scoring cards simultaneously makes the next result difficult to interpret. The goal is not to prove an archetype label correct. It is to make the deck’s resource chain more reliable.
Check format and card text before finalizing the list
Standard, Startup, introductory card pools, and historical Android: Netrunner collections do not share one legality list. Null Signal Games’ Supported Formats resource is the appropriate place to confirm current pools, rotations, and balance restrictions. If you have not selected a format, compare Standard and Startup before building or printing, or review the smaller Startup card pool as a focused entry point.
Current card text should also be checked in NetrunnerDB rather than copied from an old deck article or remembered from a previous printing. Null Signal’s rules hub directs players there for up-to-date card text. This is especially important for fast-advance tools, because a small timing or wording difference can determine whether an intended scoring sequence works.
If a finalized list will be independently printed, NetrunnerAndroid describes a workflow that can start from decklists, including NetrunnerDB imports. Independently printed cards should remain clearly distinguished from original cards. For organized play, consult the relevant organizer and the current organized-play policies rather than assuming a casual group’s practice applies at an event.
Choose the scoring problem you can solve repeatedly
Choose fast advance when your legal pool offers a consistent way to assemble and fund compressed scoring turns while keeping central servers credible. Choose glacier when your identity, economy, and ICE can maintain a remote across repeated challenges. Choose a hybrid when the secondary route covers a demonstrated weakness without crowding out the primary plan.
The practical next step is simple: select the format, choose a legal baseline list, and label every non-agenda card by the job it performs. Then test whether the deck reliably turns credits, clicks, cards, and hidden information into scoring windows. That answer matters more than whether the deck receives a perfectly pure archetype label.