Dear Passengers Pre-Launch Guide: What Crews Can Plan Now

Dear Passengers is not publicly playable on Steam as of August 17, 2026. The store still marks it as coming in 2026, with no exact launch day and no downloadable demo attached to AppID 4534960. That makes any page offering a finished flight walkthrough, exact cockpit bindings, fixed emergency sequence, or proven money route premature.

There is still enough official information to prepare intelligently. FLEXUS has established the shape of a flight: choose passengers and cargo before takeoff, accept that higher payouts tend to bring more trouble, split attention between piloting and cabin work, then deal with weather and physics-driven problems before one incident spreads. The useful guide today is therefore a planning boundary—what a crew can organize now, what the first public build needs to prove, and which attractive-looking “tips” should stay outside your playbook.

Start with the status board, not a fake departure#

Steam identifies Dear Passengers as an unreleased Windows game developed and published by FLEXUS. Its categories cover solo play and online cooperation, with broader multiplayer and co-op labels as well. The release field says only 2026. Price, a recommended PC specification, maximum crew size, local co-op, crossplay, console versions, Steam Deck support, controller support, and the way solo play covers several jobs are not specified on the store page.

The latest first-party update available through the Steam news hub is dated July 31. FLEXUS said an actual-flight gameplay video was being prepared and clarified that players fully control the plane. That clarification confirms active piloting; it does not reveal a control map, a flight model, a landing checklist, or how much time the pilot can leave the seat. Until a public build or newer developer demonstration answers those questions, a wishlist button is not a boarding pass.

Use this access rule:

• If Steam still shows only the wishlist action, there is no official public build to download from a third-party “play now” page.
• If a demo appears later, open it from the Dear Passengers Steam page or your Steam library and record the build date before following any guide.
• If a guide gives an exact date, price, player cap, or platform that Steam and FLEXUS do not, treat the claim as unverified rather than “early information.”

The confirmed flight loop has four connected decisions#

Official copy is broad, but it is specific about where pressure comes from. Read it as a chain rather than four unrelated feature bullets.

1. The manifest is the first difficulty choice

Before takeoff, the crew chooses passengers and cargo. FLEXUS ties larger payouts to more trouble: some cargo is difficult to handle, some passengers are difficult to satisfy, and trouble can begin before the aircraft leaves the ground. The store does not publish risk scores, contract tiers, cargo weights, or a best-profit formula.

For a first public session, use a baseline test instead of chasing maximum payout. If the build visibly compares rewards or warns about a passenger or cargo item, select a combination whose risk language you can understand, then change one part of the manifest on the next flight. That is a player testing method, not a claim that the game exposes a hidden difficulty number. Its purpose is to show whether the new problem came from the passenger choice, the cargo choice, the route, or a random event.

2. Cockpit and cabin are different attention zones

One crew member can pilot while others work inside the cabin. Cabin duties named by FLEXUS include serving passengers, keeping them under control, protecting cargo, and stopping a small problem from becoming a larger disaster. Those are responsibility areas, not confirmed locked classes. There is no first-party rule yet for role selection, swapping seats, character perks, or a required pilot-to-cabin ratio.

3. Routine service competes with incident control

Passengers expect food, drinks, and a smooth trip, but the game is built to interrupt that routine. This creates a useful priority question even before exact scoring is known: is the current task maintaining service, or is it preventing a second problem? A drink request can wait if an unsecured object or uncontrolled passenger is about to turn one cabin event into several. Do not translate that inference into a universal score rule until the build shows how service, safety, damage, and payout are evaluated.

4. Weather moves the problem through the aircraft

Steam explicitly includes changing weather as well as turbulence and air pockets. FLEXUS says these conditions can throw passengers, luggage, and other loose objects around the cabin. That makes communication between cockpit and cabin more than role-play: a maneuver or weather event can change what the cabin must secure, while an escalating cabin problem can demand attention the pilot cannot safely give.

Assign ownership without inventing character classes#

A crew can prepare a communication plan without pretending the final lobby rules are known. At the start of a playable session, name one person responsible for aircraft calls and one person responsible for cabin calls. If the final build supports a larger group and free movement, additional players can take temporary tasks, but the owner still decides when that task is safe to abandon.

Keep calls short enough to survive overlapping problems:

• Location: cockpit, front cabin, rear cabin, or cargo area—use the names the released UI actually shows.
• Problem: passenger, loose object, cargo, aircraft condition, or service request.
• State: seen, getting worse, contained, or needs another player.
• Next action: who is moving, who is staying, and when the crew will check again.

These are human callouts, not voice commands recognized by the game. Speaker icons appear in promotional images and Steam lists online interaction, but that does not prove proximity voice, radio channels, push-to-talk behavior, or a specific microphone setup. Use your normal group voice service until the public build documents its own system.

The failure signal for any assignment is silent duplication: two people leave the same responsibility to solve one visible joke while a less dramatic problem grows elsewhere. If that happens, return to named ownership before adding more detailed tactics. Dear Passengers is selling connected chaos; a crew plan should reduce ambiguity, not attempt to eliminate the chaos.

Triage the cascade before optimizing the payout#

Because the official premise explicitly links small trouble to larger disaster, an incident queue is more useful than a memorized emergency script. When several events compete, ask four questions in order:

1. Is aircraft control being lost? The person actively flying should not leave a live control problem merely because the cabin event looks funnier.
2. What can create a second incident? A moving passenger, loose item, exposed cargo, or worsening aircraft condition deserves attention before a task that stays local.
3. What is already contained? If a problem has stopped spreading, say so and release duplicate helpers.
4. What can be resumed? Return to food, drinks, passenger comfort, and payout work only after the active cascade has an owner.

This order is a strategy derived from the advertised interactions; it is not an official scoring hierarchy. The launch build may reward reckless recoveries, penalize delayed service heavily, or use conditions the store has not disclosed. Watch the post-flight feedback, if one exists, and revise the queue around measured consequences instead of keeping a pre-release rule out of habit.

Use the terminal as a controlled experiment#

The most misleading unofficial walkthroughs turn the terminal into a conventional airline-management checklist: route stars, aircraft condition screens, fuel distribution, exact supply buffers, crew briefings, boarding satisfaction, scheduled cabin patrols, and a fixed descent timetable. None of those systems is established by the current Steam description.

When the game becomes playable, record only what the current interface actually exposes. A compact first-flight note should contain:

• the build or demo date;
• the visible passenger and cargo choices;
• the reward or warning language shown before confirmation;
• which responsibilities could be reassigned after takeoff;
• the event that began each cascade and what finally contained it;
• the result screen language, without guessing at hidden formulas.

Change one manifest decision on the next attempt and keep the rest of the setup as similar as the game allows. If the same problem returns, you have a candidate relationship to test; if it does not, do not promote one funny flight into a guaranteed passenger trait or cargo rule.

Check the PC floor, then stop short of performance promises#

The published minimum uses the 64-bit edition of Windows 10. System memory starts at 8 GB, the renderer requires DirectX 12, and free storage is 4 GB. The CPU floor is a 2.5 GHz Intel Core i5 or an equivalent processor; the GPU line names a GeForce GTX 1060 or Radeon RX 6600 XT. Steam’s current interface-language list covers Arabic, English, Japanese, Simplified Chinese, Turkish, and Ukrainian.

Those numbers are a minimum target, not a frame-rate guarantee. FLEXUS has not posted recommended specifications, graphics presets, resolution targets, server regions, or Steam Deck compatibility. The store also does not list controller support. Before buying for a whole group, wait for the final store page or public demo to answer input and performance questions on the hardware each person actually uses.

Run a five-minute truth check when access opens#

A real first-session guide can be written quickly once a public build answers the missing questions. Before trusting any route or role advice, verify these checkpoints in the client:

1. Access: confirm the build came from Steam and note whether it is a demo, playtest, Early Access build, or full release.
2. Lobby: read the displayed maximum players, join method, late-join behavior, and whether local or cross-platform play is offered.
3. Input: open the current binding screen instead of copying a fan-made WASD, interaction, throttle, or tool list.
4. Jobs: test whether cockpit and cabin responsibilities are locked, freely swapped, assisted in solo play, or changed by the manifest.
5. Consequences: identify how the client reports damage, passenger condition, cargo loss, payout, failure, retry, and post-flight progress.

If any of these differ from an older article, the client wins. Dear Passengers is still being developed, and the July 31 update explicitly says more actual-flight material is on the way. A guide dated before that evidence should be treated as a hypothesis, not a procedure.

Leave these claims outside the cockpit for now#

Current first-party material does not support a full session walkthrough, an aircraft roster, exact controls, fixed crew classes, a landing sequence, named emergency tools, cargo statistics, passenger traits, route difficulty stars, flight duration, progression, repair economy, achievement route, or best build. It also does not confirm a public demo date, exact release day, price, maximum player count, proximity voice chat, local co-op, crossplay, Mac or Linux support, consoles, VR, or recommended PC requirements.

That boundary is not a lack of guidance; it is the guidance that keeps a crew from practicing a game someone else invented. For now, prepare the responsibility map, learn the official manifest-to-chaos loop, and keep a short verification sheet. Replace it with client-tested controls and routes only after FLEXUS opens the doors.

Sources & credits#

Identity, access status, modes, features, minimum requirements, languages, trailer metadata, and screenshots were checked against the official Dear Passengers Steam page and Steam AppID 4534960 metadata. The July 31 development boundary comes from the official Steam news hub. Images are untouched 1920×1080 JPEG screenshots supplied by FLEXUS through Steam.