Live launch day up­dates for NASA’s Artemis II test flight will be pub­lished on this page. All times are Eastern.

The Orion space­craft’s SAWs (solar ar­rays wings) have fully de­ployed, com­plet­ing a key con­fig­u­ra­tion step for the Artemis II mis­sion. Flight con­trollers in Houston con­firmed that all four wings un­folded as planned, lock­ing into place and be­gin­ning to draw power.

Each so­lar ar­ray wing ex­tends out­ward from the European Service Module, giv­ing Orion, named Integrity, a wingspan of roughly 63 feet when fully de­ployed. Each wing has 15,000 so­lar cells to con­vert sun­light to elec­tric­ity. The ar­rays can turn on two axes that al­low them to ro­tate and track the Sun, max­i­miz­ing power gen­er­a­tion as the space­craft changes at­ti­tude dur­ing its time in Earth or­bit and on its out­bound jour­ney to the Moon.

The next ma­jor mile­stones are the PRM (perigee raise ma­neu­ver) and ARB (apogee raise burn) that will in­crease the low­est and high­est points of the Orion space­craft’s or­bit and pre­pare the space­craft for deep‑space op­er­a­tions.

Following the burns, NASA will hold a post­launch news con­fer­ence at 9 p.m. from Kennedy Space Center in Florida. Following the news con­fer­ence, the Artemis II crew will be­gin prepa­ra­tions for Orion’s prox­im­ity op­er­a­tions demon­stra­tion. This demon­stra­tion will test the abil­ity to man­u­ally ma­neu­ver Orion rel­a­tive to an­other space­craft, in this case, the in­terim cryo­genic propul­sion stage af­ter sep­a­ra­tion.

Coverage on NASA+ will soon con­clude, how­ever 24/7 cov­er­age will con­tinue on NASA’s YouTube chan­nel, and keep fol­low­ing the Artemis blog for live up­dates of key mile­stones through­out the mis­sion.

Main en­gine cut­off of the SLS (Space Launch System) core stage is com­plete, and the core stage has suc­cess­fully sep­a­rated from the in­terim cryo­genic propul­sion stage and the Orion space­craft. This marks the end of the first ma­jor propul­sion phase of the Artemis II mis­sion and the tran­si­tion to up­per‑stage op­er­a­tions.

The next ma­jor mile­stone is the de­ploy­ment of the space­craft’s SAWs (solar ar­ray wings) sched­uled to be­gin ap­prox­i­mately 18 min­utes af­ter launch. Once ex­tended, the four SAWs will pro­vide con­tin­u­ous elec­tri­cal power to the space­craft through­out its jour­ney, sup­port­ing life‑sup­port sys­tems, avion­ics, com­mu­ni­ca­tions, and on­board op­er­a­tions. Deployment is a crit­i­cal step in con­fig­ur­ing Orion for the re­main­der of its time in Earth or­bit and for the out­bound trip to the Moon.

The space­craft adapter jet­ti­son fair­ings that en­close the ser­vice mod­ule and the launch abort sys­tem have sep­a­rated from the Orion space­craft. With the rocket and space­craft now fly­ing above the dens­est lay­ers of Earth’s at­mos­phere, Orion no longer re­quires the pro­tec­tive struc­tures that shielded it dur­ing the early, high‑dy­namic‑pres­sure por­tion of launch.

The next ma­jor mile­stone is core stage sep­a­ra­tion and Interim Cryogenic Propulsion Stage ig­ni­tion.

The SLS (Space Launch System) twin solid rocket boost­ers have sep­a­rated. The boost­ers, each stand­ing 177 feet tall and gen­er­at­ing more than 3.6 mil­lion pounds of thrust at liftoff, pro­vide most of the rock­et’s power dur­ing the first two min­utes of flight and sep­a­ra­tion re­duces mass and al­lows the core stage to con­tinue pro­pelling the Orion space­craft, named Integrity, to­ward or­bit.

With the boost­ers now clear, the SLS core stage re­mains the pri­mary source of thrust.

In about one minute, the space­craft adapter jet­ti­son fair­ings that en­close Orion’s ser­vice mod­ule and the launch abort sys­tem will sep­a­rate from the space­craft.

6:35 p.m.

NASA’s Artemis II SLS (Space Launch System) rocket, with the Orion spacecraft atop car­ry­ing NASA as­tro­nauts Reid Wiseman, Victor Glover, and Christina Koch, along with CSA (Canadian Space Agency) as­tro­naut Jeremy Hansen, lifted off from Kennedy Space Center’s Launch Complex 39B in Florida at 6:35 p.m. EDT to be­gin its jour­ney to deep space.

The twin solid rocket boost­ers ig­nited first, de­liv­er­ing more than 75% of the thrust needed to lift the 5.75-million-pound rocket off the pad. Their com­bined power, along with the four RS-25 en­gines al­ready at full thrust, gen­er­ated an in­cred­i­ble 8.8 mil­lion pounds of force at liftoff. As the rocket rose, the um­bil­i­cals — which pro­vided power, fuel, and data con­nec­tions dur­ing prelaunch — dis­con­nected and re­tracted into pro­tec­tive hous­ings. This en­sured the ve­hi­cle is free from ground sys­tems and fully au­tonomous for flight.

The ap­prox­i­mately 10-day Artemis II mis­sion around the Moon is the first crewed flight un­der NASA’s Artemis cam­paign. It will help test the sys­tems and hard­ware needed to con­tinue send­ing as­tro­nauts on in­creas­ingly dif­fi­cult mis­sions to ex­plore more of the Moon for sci­en­tific dis­cov­ery, eco­nomic ben­e­fits, and to con­tinue build­ing to­ward the first crewed mis­sions to Mars.

Below are the as­cent mile­stones that will oc­cur lead­ing up to core stage sep­a­ra­tion. Times may vary by sev­eral sec­onds.

The Artemis II count­down has en­tered ter­mi­nal count, and the ground launch se­quencer has taken con­trol, or­ches­trat­ing a pre­cise se­ries of au­to­mated com­mands to pre­pare the SLS (Space Launch System) rocket and Orion space­craft for liftoff at a T-0 time of 6:35 p.m. EDT.

The ground launch se­quencer en­sures that all sys­tems – from propul­sion to avion­ics – tran­si­tion into flight mode. Key ac­tions per­formed in­clude pres­sur­iz­ing pro­pel­lant tanks for op­ti­mal en­gine per­for­mance, ac­ti­vat­ing flight soft­ware and switch­ing con­trol from ground to on­board sys­tems, and per­form­ing fi­nal health checks across thou­sands of sen­sors to con­firm readi­ness.

This au­to­mated se­quence min­i­mizes hu­man in­ter­ven­tion, re­duc­ing risk and en­sur­ing syn­chro­niza­tion across com­plex sub­sys­tems. For Artemis II, this mo­ment marks the cul­mi­na­tion of years of plan­ning and test­ing, as the mis­sion moves from ground op­er­a­tions to the thresh­old of launch.

See the list be­low of the ter­mi­nal count mile­stones:

* T-4M — GLS is go for core stage aux­il­iary power unit (APU) start

Inside the ter­mi­nal count­down, teams have a few op­tions to hold the count if needed.

The launch team can hold at 6 min­utes for the du­ra­tion of the launch win­dow, less the 6 min­utes needed to launch, with­out hav­ing to re­cy­cle back to 10 min­utes.

If teams need to stop the clock be­tween T-6 min­utes and T-1 minute, 30 sec­onds, they can hold for up to 3 min­utes and re­sume the clock to launch. If they re­quire more than 3 min­utes of hold time, the count­down would re­cy­cle back to T-10.

If the clock stops af­ter T-1 minute and 30 sec­onds, but be­fore the au­to­mated launch se­quencer takes over, then teams can re­cy­cle back to T-10 to try again, pro­vided there is ad­e­quate launch win­dow re­main­ing.

After han­dover to the au­to­mated launch se­quencer, any is­sue that would stop the count­down would lead to con­clud­ing the launch at­tempt for that day.

Artemis II Launch Director Charlie Blackwell-Thompson conducted one of the most im­por­tant steps be­fore liftoff: the “go/no-go” poll for the team to pro­ceed with the fi­nal 10 min­utes of the count­down known as ter­mi­nal count.

A unan­i­mous “go” across the board sig­nals that Artemis II is fully pre­pared to pro­ceed to­ward launch. This mo­ment rep­re­sents the cul­mi­na­tion of years of plan­ning and hours of metic­u­lous pre-launch work, bring­ing the mis­sion to the thresh­old of his­tory.

The launch team has made the de­ci­sion to ex­tend the T-10 minute hold ahead of to­day’s launch to give en­gi­neers time to work through fi­nal prepa­ra­tions for liftoff. There is a two-hour win­dow in which Artemis II could launch, and a new liftoff time will be set shortly

NASA’s Artemis II closeout crew com­pleted its fi­nal tasks and de­parted Launch Complex 39B at NASA’s Kennedy Space Center in Florida. After hours of metic­u­lous work as­sist­ing the as­tro­nauts with suit-up, hatch clo­sure, and crit­i­cal space­craft checks, the team ex­ited the White Room and left the Orion space­craft sealed and ready for flight.

This de­par­ture marks a ma­jor tran­si­tion in launch op­er­a­tions: the space­craft is now fully con­fig­ured, and re­spon­si­bil­ity shifts to the launch con­trol team for the fi­nal count­down. The close­out crew’s pre­ci­sion and ex­per­tise en­sure that every con­nec­tion, seal, and sys­tem is ver­i­fied be­fore they step away – mak­ing this mo­ment a key mile­stone on the path to liftoff.

Engineers in­ves­ti­gated a sen­sor on the launch abort sys­tem’s at­ti­tude con­trol mo­tor con­troller bat­tery that showed a higher tem­per­a­ture than would be ex­pected. It is be­lieved to be an in­stru­men­ta­tion is­sue and will not af­fect to­day’s launch.

The weather con­tin­ues to co­op­er­ate and has now been up­graded to 90% go for launch.

Engineers have now re­solved an is­sue with the hard­ware that com­mu­ni­cates with the flight ter­mi­na­tion sys­tem that would have pre­vented the ground from send­ing a sig­nal to de­struct the rocket if it were to veer off course dur­ing as­cent, to pro­tect pub­lic safety. A con­fi­dence test was per­formed to en­sure that the hard­ware is ready to sup­port to­day’s launch.

Meanwhile, tech­ni­cians have com­pleted the launch abort sys­tem hatch clo­sure – an es­sen­tial step that en­sures the Orion space­craft is fully sealed and ready for flight. The hatch pro­vides an ad­di­tional pro­tec­tive bar­rier for the crew mod­ule, de­signed to safe­guard as­tro­nauts dur­ing the Artemis II flight path and, if nec­es­sary, en­able a rapid es­cape in the event of an emer­gency.

During this phase, the close­out team ver­i­fies hatch align­ment, en­gages lock­ing mech­a­nisms, and con­firms pres­sure in­tegrity. These checks guar­an­tee that the launch abort sys­tem hatch can per­form its func­tion flaw­lessly, main­tain­ing struc­tural in­tegrity un­der ex­treme launch con­di­tions. With the hatch se­cured, Orion en­ters its fi­nal con­fig­u­ra­tion for liftoff, mark­ing one of the last ma­jor mile­stones be­fore fu­el­ing and launch.

Although the count­down to to­day’s Artemis II launch is con­tin­u­ing to progress, the Eastern Range has iden­ti­fied an is­sue that they are cur­rently work­ing to re­solve re­lated to their com­mu­ni­ca­tion with the flight ter­mi­na­tion sys­tem. The flight ter­mi­na­tion sys­tem is a safety sys­tem that al­lows en­gi­neers on the ground to send a sig­nal to de­struct the rocket if it were to veer off course dur­ing as­cent, to pro­tect pub­lic safety. Without as­sur­ance that this sys­tem would work if needed, to­day’s launch would be no-go. However, en­gi­neers have de­vised a way to ver­ify the sys­tem and are cur­rently prepar­ing to test this so­lu­tion.

Technicians be­gan in­stalling the crew mod­ule hatch ser­vice panel on the Orion space­craft, an im­por­tant step in fi­nal launch prepa­ra­tions. This panel pro­tects key con­nec­tions and en­sures the hatch area is se­cure for flight.

As part of cur­rent close­out ac­tiv­i­ties, teams are con­firm­ing all sys­tems around the hatch are prop­erly sealed and ready for the mis­sion.

With the hatch area se­cured, teams will con­tinue fi­nal checks and count­down op­er­a­tions at Launch Pad 39B at NASA’s Kennedy Space Center in Florida, bring­ing us closer to send­ing as­tro­nauts on a his­toric jour­ney around the Moon.

NASA en­gi­neers have con­ducted coun­ter­bal­ance mech­a­nism op­er­a­tions and are now per­form­ing hatch seal pres­sure de­cay checks in­side the White Room at Launch Complex 39B. These steps en­sure Orion’s hatch main­tains proper pres­sure in­tegrity and that the coun­ter­bal­ance sys­tem func­tions as de­signed for launch con­di­tions.

The coun­ter­bal­ance mech­a­nism is a pre­ci­sion-en­gi­neered as­sem­bly that off­sets the weight of the crew mod­ule hatch, al­low­ing tech­ni­cians to open and close it smoothly with­out in­tro­duc­ing stress on the hinge or seal. This sys­tem uses cal­i­brated springs and dampers to main­tain align­ment and pre­vent sud­den move­ments, which is es­sen­tial for pre­serv­ing the hatch’s air­tight seal. During this phase, tech­ni­cians ver­ify the mech­a­nis­m’s load dis­tri­b­u­tion and con­firm that its lock­ing fea­tures en­gage cor­rectly un­der sim­u­lated launch loads.

Following these ad­just­ments, the team per­forms seal pres­sur­iza­tion de­cay checks – mon­i­tor­ing pres­sure loss over time to con­firm the hatch’s in­tegrity. These checks are vi­tal for as­tro­naut safety, en­sur­ing the cabin re­mains se­cure in all mis­sion phases.

NASA’s Artemis II close­out crew is now com­plet­ing one of the most crit­i­cal steps be­fore launch: prepar­ing and clos­ing the crew mod­ule hatch to the Orion space­craft. Inside the White Room at Launch Complex 39B, the close­out crew is work­ing metic­u­lously to in­spect seals, se­cure fas­ten­ers, and ver­ify that the hatch is air­tight.

This process en­sures Orion is fully pres­sur­ized and ready for flight. Once the hatch is closed and locked, the as­tro­nauts are of­fi­cially sealed in­side their space­craft, mark­ing a ma­jor mile­stone on the path to liftoff.

NASA’s Artemis II crew mem­bers are board­ing the agen­cy’s Orion space­craft to be­gin com­mu­ni­ca­tion checks to con­firm voice links with mis­sion con­trol and on­board sys­tems.

Before en­ter­ing the space­craft that will be their home on the ap­prox­i­mately 10-day jour­ney around the Moon and back, all four crew­mates signed the in­side of the White Room, an area at the end of the crew ac­cess arm that pro­vides ac­cess to the space­craft. The term “White Room” dates to NASA’s Gemini pro­gram, and to honor this hu­man space­flight tra­di­tion, the room re­mains white to­day.

The Artemis II closeout crew is now work­ing to help the as­tro­nauts en­ter the Orion space­craft and make fi­nal prepa­ra­tions for their nearly 700,000-mile trip to the Moon and back. As part of the process, the close­out crew is help­ing the as­tro­nauts don their Orion Crew Survival System helmets and gloves, as well as board Orion and get buck­led in.

A short time from now, the close­out crew will close the crew mod­ule and ex­te­rior launch abort sys­tem hatches. Even a sin­gle strand of hair in­side the hatch doors could po­ten­tially pose is­sues with clos­ing ei­ther hatch, so the process is care­fully done and takes up to four hours. Each step in the close­out process en­sures air­tight seals and com­mu­ni­ca­tion readi­ness for the mis­sion ahead.

Following com­mu­ni­ca­tion checks, the team per­formed suit leak checks – a vi­tal safety pro­ce­dure en­sur­ing each pres­sure suit main­tains in­tegrity in case of cabin de­pres­sur­iza­tion. These op­er­a­tions are es­sen­tial for crew readi­ness and mis­sion as­sur­ance, mark­ing one of the fi­nal phases be­fore hatch clo­sure and launch prepa­ra­tions.

With assistance from the close­out crew, the Artemis II crew are care­fully don­ning their hel­mets and gloves – fi­nal­iz­ing suit in­tegrity checks be­fore board­ing the Orion space­craft.

This step is more than cer­e­mo­nial; it en­sures air­tight seals and com­mu­ni­ca­tion readi­ness for the mis­sion ahead. The close­out crew plays a vi­tal role, guid­ing the as­tro­nauts through these pro­ce­dures and con­firm­ing every con­nec­tion is se­cure be­fore hatch clo­sure.

Stay tuned as we con­tinue to fol­low the Artemis II team through each count­down mile­stone on their path to liftoff.

NASA’s Artemis II crew NASA as­tro­nauts Reid Wiseman, Victor Glover, and Christina Koch, along with CSA (Canadian Space Agency) as­tro­naut Jeremy Hansen, arrived at Launch Complex 39B at the agen­cy’s Kennedy Space Center in Florida, where the agen­cy’s SLS (Space Launch System) rocket with Orion space­craft atop stands ready for launch. The open­ing of to­day’s launch win­dow is slated for just over 4 hours from now, at 6:24 p.m. EDT.

In the next few min­utes, the crew will take the el­e­va­tor up the pad’s fixed ser­vice struc­ture and walk down the cli­mate-con­trolled crew ac­cess arm to the White Room, their fi­nal stop be­fore climb­ing aboard their Orion space­craft. In this clean, con­trolled en­vi­ron­ment at the end of the crew ac­cess arm, the close­out crew will as­sist the as­tro­nauts with hatch op­er­a­tions and ver­ify that all safety sys­tems are ready for launch.

Since the late 1960s, pads A and B at Kennedy’s Launch Complex 39 have sup­ported America’s ma­jor space pro­grams, with Pad A used most fre­quently for launches un­der the Space Shuttle Program. After the re­tire­ment of the shut­tle in 2011, Pad A helped usher in a new era of hu­man space­flight as launch pad for the agen­cy’s Commercial Crew Program, which re­turned hu­man space­flight ca­pa­bil­ity to the United States. Pad B saw the launch of NASA’s Artemis I mis­sion in November 2022 and will con­tinue to be the pri­mary launch pad for America’s ef­forts to re­turn to hu­mans the Moon.

Just mo­ments ago, NASA’s Artemis II flight crew be­gan the walk that every NASA as­tro­naut has made since Apollo 7 in 1968, head­ing to the el­e­va­tor and down through the dou­ble doors be­low the Neil A. Armstrong Building’s Astronaut Crew Quarters at NASA’s Kennedy Space Center in Florida.

Before they left the suit-up room, the crew com­pleted one last piece of un­fin­ished busi­ness — a card game. A long-held space­flight tra­di­tion, NASA crews play cards be­fore leav­ing the crew quar­ters ahead of launch un­til the com­man­der, in this in­stance NASA as­tro­naut Reid Wiseman, loses. It is hoped that by los­ing, the com­man­der burns off all his or her bad luck, thereby clear­ing the mis­sion for only good luck.

NASA’s Artemis II is the first crewed mis­sion of the Artemis pro­gram and will carry Wiseman and fel­low NASA as­tro­nauts Vic­tor Glover and Christina Koch, as well as CSA (Canadian Space Agency) as­tro­naut Jeremy Hansen on an ap­prox­i­mately 10-day mis­sion around the Moon and back to Earth.

The first crewed deep-space flight in over 50 years, Artemis II is ex­pected to send the crew far­ther from Earth than any pre­vi­ous hu­man mis­sion, po­ten­tially break­ing the record of about 248,655 miles (400,171 km) from Earth set by Apollo 13 dur­ing its lu­nar free-re­turn tra­jec­tory. This mile­stone will oc­cur dur­ing the lu­nar flyby phase, when the crew trav­els on a free-re­turn tra­jec­tory around the Moon, which al­lows the space­craft to loop around the Moon and re­turn to Earth with­out en­ter­ing lu­nar or­bit.

During the test flight, NASA will test life-sup­port sys­tems and crit­i­cal op­er­a­tions in deep space, paving the way for fu­ture lu­nar land­ings and Mars ex­plo­ration.

Having received good­byes and well wishes from their fam­i­lies and friends, the crew em­barks on the 20-minute jour­ney to Kennedy’s Launch Pad 39B and their await­ing space­craft.

NASA’s pad res­cue and close­out crew teams have ar­rived at Launch Complex 39B at the agen­cy’s Kennedy Space Center in Florida to en­sure safety and readi­ness dur­ing the crit­i­cal fu­el­ing op­er­a­tions. These spe­cial­ized teams play a vi­tal role in pro­tect­ing per­son­nel and hard­ware through­out the count­down.

The pad res­cue team will be po­si­tioned to re­spond im­me­di­ately in the un­likely event of an emer­gency, en­sur­ing safe evac­u­a­tion pro­ce­dures for pad per­son­nel. The res­cue team is equipped with ad­vanced gear and trained for rapid crew ex­trac­tion, fire sup­pres­sion, and haz­ard mit­i­ga­tion. Their pres­ence en­sures as­tro­naut safety re­mains the top pri­or­ity, pro­vid­ing an all-im­por­tant layer of pro­tec­tion as fu­el­ing op­er­a­tions and sys­tem checks con­tinue.

The closeout crew is re­spon­si­ble for clos­ing the Orion crew mod­ule and launch abort sys­tem hatches, se­cur­ing ac­cess points, ver­i­fy­ing pad con­fig­u­ra­tions, and main­tain­ing the in­tegrity of the launch area dur­ing pro­pel­lant load­ing and sys­tem checks. Their work is crit­i­cal for guar­an­tee­ing a se­cure en­vi­ron­ment for the as­tro­nauts be­fore the launch pad is cleared for liftoff op­er­a­tions.

These teams are es­sen­tial for mit­i­gat­ing risk and sup­port­ing the com­plex chore­og­ra­phy of Artemis II’s prelaunch ac­tiv­i­ties. With both teams in place, Artemis II remains on track for its his­toric mis­sion to send as­tro­nauts around the Moon.

NASA as­tro­nauts Reid Wiseman, com­man­der; Victor Glover, pi­lot; and Christina Koch, mis­sion spe­cial­ist; along with CSA (Canadian Space Agency) as­tro­naut Jeremy Hansen, mis­sion spe­cial­ist, are suit­ing up in­side the Astronaut Crew Quarters of the Neil A. Armstrong Operations and Checkout Building at the agen­cy’s Kennedy Space Center in Florida.

A team of suit tech­ni­cians help the crew put on their Orion Crew Survival System suits, which are each tai­lored for mo­bil­ity and com­fort while en­sur­ing max­i­mum safety dur­ing the dy­namic phases of flight. The bright or­ange space­suits are de­signed to pro­tect them on their jour­ney and fea­ture many im­prove­ments from head to toe to the suits worn on the space shut­tle. NASA reengi­neered many el­e­ments to im­prove safety and range of mo­tion for Artemis as­tro­nauts, and in­stead of the small, medium, and large sizes from the shut­tle era, they are cus­tom fit for each crew mem­ber.

The outer layer is fire-re­sis­tant, and a stronger zip­per al­lows as­tro­nauts to quickly put the suit on. Improved ther­mal man­age­ment will help keep them cool and dry. A lighter, stronger hel­met im­proves com­fort and com­mu­ni­ca­tion, and the gloves are more durable and touch-screen com­pat­i­ble. Better-fitting boots also pro­vide pro­tec­tion in the case of fire and help an as­tro­naut move more swiftly.

The suits’ de­sign and en­gi­neer­ing en­hance­ments pro­vide an ad­di­tional layer of pro­tec­tion for as­tro­nauts and en­sure they re­turn home safely from deep space mis­sions.

During suit-up, teams will check for leaks and en­sure that all con­nect­ing life sup­port sys­tems, in­clud­ing air and power, are op­er­at­ing nom­i­nally ahead of the crew’s ride to NASA Kennedy’s Launch Complex 39B.

With NASA teams now main­tain­ing the liq­uid oxy­gen lev­els in the in­terim cryo­genic propul­sion, all cryo­genic stages of the SLS (Space Launch System) rocket have tran­si­tioned to re­plen­ish mode dur­ing the Artemis II launch count­down. This in­cludes the core stage and SLS up­per stage, en­sur­ing both liq­uid hy­dro­gen and liq­uid oxy­gen tanks re­main at flight-ready lev­els.

Replenish mode is es­sen­tial for main­tain­ing sta­ble pro­pel­lant quan­ti­ties and pres­sure as su­per-cold fu­els nat­u­rally boil off over time. Continuous ad­just­ments keep the rocket fully fu­eled and ready for ig­ni­tion, sup­port­ing the RS-25 en­gines on the core stage and the RL10 en­gine on the SLS up­per stage for their es­sen­tial roles in launch and translu­nar in­jec­tion.

These mile­stones co­in­cide with the Artemis II count­down en­ter­ing a planned 1-hour and 10-minute built-in hold. This sched­uled pause al­lows teams to com­plete cru­cial sys­tem checks, ver­ify launch readi­ness, and ad­dress any last-minute ad­just­ments be­fore pro­ceed­ing to­ward crew ingress and fi­nal fu­el­ing op­er­a­tions.

During this hold, en­gi­neers re­view data from cryo­genic load­ing, propul­sion sys­tems, and com­mu­ni­ca­tions to en­sure all pa­ra­me­ters meet strict safety and per­for­mance cri­te­ria. The hold also pro­vides flex­i­bil­ity for re­solv­ing mi­nor is­sues with­out im­pact­ing the over­all launch time­line.

Once the hold con­cludes, the count­down will re­sume with prepa­ra­tions for as­tro­naut ar­rival at Launch Pad 39B at NASA’s Kennedy Space Center in Florida.

NASA’s Artemis II astronauts received a fi­nal weather brief­ing in­side the Astronaut Crew Quarters of the Neil A. Armstrong Operations and Checkout Building at the agen­cy’s Kennedy Space Center in Florida, as part of prelaunch prepa­ra­tions.

This weather up­date pro­vides as­tro­nauts and mis­sion teams with the lat­est con­di­tions at NASA Kennedy’s Launch Pad 39B, the sur­round­ing re­cov­ery zones, and po­ten­tial abort sites along Artemis II’s flight path. Accurate weather fore­cast­ing is es­sen­tial for pro­tect­ing crew and hard­ware, as even mi­nor changes can im­pact count­down de­ci­sions and flight dy­nam­ics.

NASA as­tro­nauts Reid Wiseman, com­man­der; Vic­tor Glover, pi­lot; and Christina Koch, mis­sion spe­cial­ist; along with CSA (Canadian Space Agency) as­tro­naut Je­remy Hansen, mis­sion spe­cial­ist, were briefed on wind speeds, pre­cip­i­ta­tion, light­ning risk, and sea states for splash­down con­tin­gen­cies, en­sur­ing all safety cri­te­ria are met be­fore pro­ceed­ing with launch op­er­a­tions.

Weather of­fi­cials with NASA and the U. S. Space Force’s Space Launch Delta 45 are track­ing 80% fa­vor­able con­di­tions dur­ing the launch win­dow, with pri­mary con­cerns be­ing the cu­mu­lus cloud rule, flight through pre­cip­i­ta­tion rule, and ground winds.

With the weather brief­ing com­plete, the crew and ground teams re­main aligned and ready to con­tinue to­ward liftoff, keep­ing Artemis II on track for its his­toric mis­sion to send as­tro­nauts around the Moon.

NASA teams also have be­gun liq­uid oxy­gen (LOX) top­ping process for the in­terim cryo­genic propul­sion stage, or SLS (Space Launch System) rocket up­per stage, dur­ing the Artemis II launch count­down. This step fol­lows the fast fill phase and en­sures the liq­uid oxy­gen tank reaches full ca­pac­ity with su­per-cold ox­i­dizer.

Live cov­er­age of Artemis II tank­ing op­er­a­tions con­tin­ues on NASA’s YouTube chan­nel. NASA’s full launch cov­er­age be­gins at 1 p.m. EDT on NASA+, Amazon Prime, and YouTube. You can con­tinue to fol­low the Artemis blog from launch to splash­down for mis­sion up­dates.

Liquid oxy­gen (LOX) fast fill is now com­plete for the SLS (Space Launch System) up­per stage, mark­ing an­other ma­jor mile­stone in tank­ing op­er­a­tions. Teams have con­firmed the up­per stage is in good shape and are pro­ceed­ing with the LOX vent and re­lief test. This step helps ver­ify proper pres­sure reg­u­la­tion and en­sures the sys­tem is ready to tran­si­tion into top­ping and, later, re­plen­ish op­er­a­tions.

NASA teams are now main­tain­ing the liq­uid oxy­gen lev­els in the SLS (Space Launch System) rocket core stage through re­plen­ish mode. This phase fol­lows the com­ple­tion of liq­uid oxy­gen fast fill and top­ping, en­sur­ing the ox­i­dizer re­mains at flight-ready lev­els through­out the fi­nal count­down.

NASA teams are in fast fill of liq­uid oxy­gen (LOX) into the in­terim cryo­genic propul­sion stage as part of the Artemis II launch count­down. This phase rapidly loads the ox­i­dizer af­ter chill­down is com­plete, bring­ing the SLS (Space Launch System) rocket up­per stage closer to full readi­ness for its role in send­ing the Orion space­craft into a high Earth or­bit ahead of a prox­im­ity op­er­a­tions demon­stra­tion test and Orion’s translu­nar in­jec­tion burn.

NASA teams have tran­si­tioned the in­terim cryo­genic propul­sion stage liq­uid hy­dro­gen tank to re­plen­ish mode dur­ing the Artemis II countdown. This phase fol­lows the suc­cess­ful top­ping process and en­sures the tank re­mains at flight-ready lev­els all the way to launch.

NASA teams have be­gun the top­ping phase for the in­terim cryo­genic propul­sion stage liq­uid hy­dro­gen (LH2) tank. This crit­i­cal step oc­curs af­ter suc­cess­ful chill­down and vent-and-re­lief checks, en­sur­ing the tank reaches full ca­pac­ity with su­per-cold liq­uid hy­dro­gen.

Replenish is the fi­nal step in the fu­el­ing process, de­signed to main­tain the cor­rect LH2 lev­els as the su­per-cold pro­pel­lant nat­u­rally boils off over time. This con­tin­u­ous, low-rate flow keeps the tanks topped off and ther­mally sta­ble, en­sur­ing the rocket re­mains fully fu­eled and ready for liftoff.

From chill­down to re­plen­ish, every phase of fu­el­ing is care­fully man­aged to pro­tect hard­ware and guar­an­tee mis­sion suc­cess. With re­plen­ish un­der­way, Artemis II is in its fi­nal stretch to­ward launch and hu­man­i­ty’s next gi­ant leap.

Topping is the process of adding small amounts of LH2 to the tanks af­ter fast fill is com­plete, en­sur­ing they re­main at full ca­pac­ity as the su­per-cold pro­pel­lant nat­u­rally boils off. This step is crit­i­cal for main­tain­ing the pre­cise lev­els needed for launch while keep­ing the sys­tem ther­mally sta­ble.

The Artemis II launch team tran­si­tioned to the fast fill of liq­uid hy­dro­gen (LH2) for the in­terim cryo­genic propul­sion stage, or SLS (Space Launch System) rocket upper stage.

After completing the chill­down phase, this step rapidly loads su­per-cold LH2 into the SLS up­per stage tanks, en­sur­ing the up­per stage is fu­eled and ready to per­form its fun­da­men­tal role of rais­ing the Orion space­craft into a high Earth or­bit ahead of a prox­im­ity op­er­a­tions demon­stra­tion test and Orion’s translu­nar in­jec­tion burn.

Fast fill ac­cel­er­ates the fu­el­ing process while main­tain­ing safety, mark­ing an­other ma­jor mile­stone in the count­down as Artemis II moves closer to liftoff.

The Artemis II launch team has be­gun the liq­uid hy­dro­gen chill­down for the in­terim cryo­genic propul­sion stage, or SLS (Space Launch System) rocket upper stage.

This process grad­u­ally cools the in­terim cryo­genic propul­sion stage fuel lines and com­po­nents to cryo­genic tem­per­a­tures us­ing su­per-cold liq­uid hy­dro­gen. The chill­down step is es­sen­tial to pre­vent ther­mal shock and en­sure the stage is prop­erly con­di­tioned for full pro­pel­lant load­ing. By sta­bi­liz­ing the sys­tem at these ex­treme tem­per­a­tures, en­gi­neers guar­an­tee safe and ef­fi­cient fu­el­ing for the up­per stage that will help po­si­tion Orion into high Earth or­bit for its jour­ney to­ward the Moon.

NASA as­tro­nauts Reid Wiseman, Victor Glover, and Christina Koch, along with CSA (Canadian Space Agency) as­tro­naut Je­remy Hansen have of­fi­cially be­gun their launch day with a sched­uled wake-up call at 9:25 a.m., mark­ing the start of their fi­nal prepa­ra­tions for the his­toric Artemis II mis­sion around the Moon.

The Artemis II launch team tran­si­tioned to the fast fill of liq­uid hy­dro­gen (LH2) into the SLS (Space Launch System) rocket core stage.

Artemis II is NASA’s first crewed mis­sion un­der the Artemis pro­gram and will launch from the agen­cy’s Kennedy Space Center in Florida. It will send NASA as­tro­nauts Reid Wiseman, Victor Glover, Christina Koch, and CSA (Canadian Space Agency) as­tro­naut Jeremy Hansen on an ap­prox­i­mately 10-day jour­ney around the Moon. Among ob­jec­tives, the agency will test the Orion space­craft’s life sup­port sys­tems for the first time with peo­ple and lay the ground­work for fu­ture crewed Artemis mis­sions.

The cost of build­ing soft­ware has dras­ti­cally de­creased. We re­cently re­built Next.js in one week us­ing AI cod­ing agents. But for the past two months our agents have been work­ing on an even more am­bi­tious pro­ject: re­build­ing the WordPress open source pro­ject from the ground up.

WordPress pow­ers over 40% of the Internet. It is a mas­sive suc­cess that has en­abled any­one to be a pub­lisher, and cre­ated a global com­mu­nity of WordPress de­vel­op­ers. But the WordPress open source pro­ject will be 24 years old this year. Hosting a web­site has changed dra­mat­i­cally dur­ing that time. When WordPress was born, AWS EC2 did­n’t ex­ist. In the in­ter­ven­ing years, that task has gone from rent­ing vir­tual pri­vate servers, to up­load­ing a JavaScript bun­dle to a glob­ally dis­trib­uted net­work at vir­tu­ally no cost. It’s time to up­grade the most pop­u­lar CMS on the Internet to take ad­van­tage of this change.

Our name for this new CMS is EmDash. We think of it as the spir­i­tual suc­ces­sor to WordPress. It’s writ­ten en­tirely in TypeScript. It is server­less, but you can run it on your own hard­ware or any plat­form you choose. Plugins are se­curely sand­boxed and can run in their own iso­late, via Dynamic Workers, solv­ing the fun­da­men­tal se­cu­rity prob­lem with the WordPress plu­gin ar­chi­tec­ture. And un­der the hood, EmDash is pow­ered by Astro, the fastest web frame­work for con­tent-dri­ven web­sites.

EmDash is fully open source, MIT li­censed, and avail­able on GitHub. While EmDash aims to be com­pat­i­ble with WordPress func­tion­al­ity, no WordPress code was used to cre­ate EmDash. That al­lows us to li­cense the open source pro­ject un­der the more per­mis­sive MIT li­cense. We hope that al­lows more de­vel­op­ers to adapt, ex­tend, and par­tic­i­pate in EmDash’s de­vel­op­ment.

You can de­ploy the EmDash v0.1.0 pre­view to your own Cloudflare ac­count, or to any Node.js server to­day as part of our early de­vel­oper beta:

Or you can try out the ad­min in­ter­face here in the EmDash Playground:

The story of WordPress is a tri­umph of open source that en­abled pub­lish­ing at a scale never be­fore seen. Few pro­jects have had the same recog­nis­able im­pact on the gen­er­a­tion raised on the Internet. The con­trib­u­tors to WordPress’s core, and its many thou­sands of plu­gin and theme de­vel­op­ers have built a plat­form that de­moc­ra­tised pub­lish­ing for mil­lions; many lives and liveli­hoods be­ing trans­formed by this ubiq­ui­tous soft­ware.

There will al­ways be a place for WordPress, but there is also a lot more space for the world of con­tent pub­lish­ing to grow. A decade ago, peo­ple pick­ing up a key­board uni­ver­sally learned to pub­lish their blogs with WordPress. Today it’s just as likely that per­son picks up Astro, or an­other TypeScript frame­work to learn and build with. The ecosys­tem needs an op­tion that em­pow­ers a wide au­di­ence, in the same way it needed WordPress 23 years ago.

EmDash is com­mit­ted to build­ing on what WordPress cre­ated: an open source pub­lish­ing stack that any­one can in­stall and use at lit­tle cost, while fix­ing the core prob­lems that WordPress can­not solve.

WordPress’ plu­gin ar­chi­tec­ture is fun­da­men­tally in­se­cure. 96% of se­cu­rity is­sues for WordPress sites orig­i­nate in plu­g­ins. In 2025, more high sever­ity vul­ner­a­bil­i­ties were found in the WordPress ecosys­tem than the pre­vi­ous two years com­bined.

Why, af­ter over two decades, is WordPress plu­gin se­cu­rity so prob­lem­atic?

A WordPress plu­gin is a PHP script that hooks di­rectly into WordPress to add or mod­ify func­tion­al­ity. There is no iso­la­tion: a WordPress plu­gin has di­rect ac­cess to the WordPress site’s data­base and filesys­tem. When you in­stall a WordPress plu­gin, you are trust­ing it with ac­cess to nearly every­thing, and trust­ing it to han­dle every ma­li­cious in­put or edge case per­fectly.

EmDash solves this. In EmDash, each plu­gin runs in its own iso­lated sand­box: a Dynamic Worker. Rather than giv­ing di­rect ac­cess to un­der­ly­ing data, EmDash pro­vides the plu­gin with ca­pa­bil­i­ties via bind­ings, based on what the plu­gin ex­plic­itly de­clares that it needs in its man­i­fest. This se­cu­rity model has a strict guar­an­tee: an EmDash plu­gin can only per­form the ac­tions ex­plic­itly de­clared in its man­i­fest. You can know and trust up­front, be­fore in­stalling a plu­gin, ex­actly what you are grant­ing it per­mis­sion to do, sim­i­lar to go­ing through an OAuth flow and grant­ing a 3rd party app a spe­cific set of scoped per­mis­sions.

For ex­am­ple, a plu­gin that sends an email af­ter a con­tent item gets saved looks like this:

im­port { de­fine­Plu­gin } from “emdash”;

ex­port de­fault () =>

de­fine­Plu­gin({

id: “notify-on-publish”,

ver­sion: “1.0.0”,

ca­pa­bil­i­ties: [“read:content”, “email:send”],

hooks: {

“content:afterSave”: async (event, ctx) => {

if (event.collection !== “posts” || event.con­tent.sta­tus !== “published”) re­turn;

await ctx.email!.send({

to: “[email protected]”,

sub­ject: `New post pub­lished: ${event.content.title}`,

text: `“${event.content.title}” is now live.`,

ctx.log.info(`No­ti­fied ed­i­tors about ${event.content.id}`);

This plu­gin ex­plic­itly re­quests two ca­pa­bil­i­ties: con­tent:af­ter­Save to hook into the con­tent life­cy­cle, and email:send to ac­cess the ctx.email func­tion. It is im­pos­si­ble for the plu­gin to do any­thing other than use these ca­pa­bil­i­ties. It has no ex­ter­nal net­work ac­cess. If it does need net­work ac­cess, it can spec­ify the ex­act host­name it needs to talk to, as part of its de­f­i­n­i­tion, and be granted only the abil­ity to com­mu­ni­cate with a par­tic­u­lar host­name.

And in all cases, be­cause the plug­in’s needs are de­clared sta­t­i­cally, up­front, it can al­ways be clear ex­actly what the plu­gin is ask­ing for per­mis­sion to be able to do, at in­stall time. A plat­form or ad­min­is­tra­tor could de­fine rules for what plu­g­ins are or aren’t al­lowed to be in­stalled by cer­tain groups of users, based on what per­mis­sions they re­quest, rather than an al­lowlist of ap­proved or safe plu­g­ins.

WordPress plu­gin se­cu­rity is such a real risk that WordPress.org man­u­ally re­views and ap­proves each plu­gin in its mar­ket­place. At the time of writ­ing, that re­view queue is over 800 plu­g­ins long, and takes at least two weeks to tra­verse. The vul­ner­a­bil­ity sur­face area of WordPress plu­g­ins is so wide that in prac­tice, all par­ties rely on mar­ket­place rep­u­ta­tion, rat­ings and re­views. And be­cause WordPress plu­g­ins run in the same ex­e­cu­tion con­text as WordPress it­self and are so deeply in­ter­twined with WordPress code, some ar­gue they must carry for­ward WordPress’ GPL li­cense.

These re­al­i­ties com­bine to cre­ate a chill­ing ef­fect on de­vel­op­ers build­ing plu­g­ins, and on plat­forms host­ing WordPress sites.

Plugin se­cu­rity is the root of this prob­lem. Marketplace busi­nesses pro­vide trust when par­ties oth­er­wise can­not eas­ily trust each other. In the case of the WordPress mar­ket­place, the plu­gin se­cu­rity risk is so large and prob­a­ble that many of your cus­tomers can only rea­son­ably trust your plu­gin via the mar­ket­place. But in or­der to be part of the mar­ket­place your code must be li­censed in a way that forces you to give it away for free every­where other than that mar­ket­place. You are locked in.

EmDash plu­g­ins have two im­por­tant prop­er­ties that mit­i­gate this mar­ket­place lock-in:

Plugins can have any li­cense: they run in­de­pen­dently of EmDash and share no code. It’s the plu­gin au­thor’s choice. Plugin code runs in­de­pen­dently in a se­cure sand­box: a plu­gin can be pro­vided to an EmDash site, and trusted, with­out the EmDash site ever see­ing the code.

The first part is straight­for­ward — as the plu­gin au­thor, you choose what li­cense you want. The same way you can when pub­lish­ing to NPM, PyPi, Packagist or any other reg­istry. It’s an open ecosys­tem for all, and up to the com­mu­nity, not the EmDash pro­ject, what li­cense you use for plu­g­ins and themes.

The sec­ond part is where EmDash’s plu­gin ar­chi­tec­ture breaks free of the cen­tral­ized mar­ket­place.

Developers need to rely on a third party mar­ket­place hav­ing vet­ted the plu­gin far less to be able to make de­ci­sions about whether to use or trust it. Consider the ex­am­ple plu­gin above that sends emails af­ter con­tent is saved; the plu­gin de­clares three things:

It only runs on the con­tent:af­ter­Save hookIt has the read:con­tent ca­pa­bil­i­tyIt has the email:send ca­pa­bil­ity

The plu­gin can have tens of thou­sands of lines of code in it, but un­like a WordPress plu­gin that has ac­cess to every­thing and can talk to the pub­lic Internet, the per­son adding the plu­gin knows ex­actly what ac­cess they are grant­ing to it. The clearly de­fined bound­aries al­low you to make in­formed de­ci­sions about se­cu­rity risks and to zoom in on more spe­cific risks that re­late di­rectly to the ca­pa­bil­i­ties the plu­gin is given.

The more that both sites and plat­forms can trust the se­cu­rity model to pro­vide con­straints, the more that sites and plat­forms can trust plu­g­ins, and break free of cen­tral­ized con­trol of mar­ket­places and rep­u­ta­tion. Put an­other way: if you trust that food safety is en­forced in your city, you’ll be ad­ven­tur­ous and try new places. If you can’t trust that there might be a sta­ple in your soup, you’ll be con­sult­ing Google be­fore every new place you try, and it’s harder for every­one to open new restau­rants.

The busi­ness model of the web is at risk, par­tic­u­larly for con­tent cre­ators and pub­lish­ers. The old way of mak­ing con­tent widely ac­ces­si­ble, al­low­ing all clients free ac­cess in ex­change for traf­fic, breaks when there is no hu­man look­ing at a site to ad­ver­tise to, and the client is in­stead their agent ac­cess­ing the web on their be­half. Creators need ways to con­tinue to make money in this new world of agents, and to build new kinds of web­sites that serve what peo­ple’s agents need and will pay for. Decades ago a new wave of cre­ators cre­ated web­sites that be­came great busi­nesses (often us­ing WordPress to power them) and a sim­i­lar op­por­tu­nity ex­ists to­day.

x402 is an open, neu­tral stan­dard for Internet-native pay­ments. It lets any­one on the Internet eas­ily charge, and any client pay on-de­mand, on a pay-per-use ba­sis. A client, such as an agent, sends a HTTP re­quest and re­ceives a HTTP 402 Payment Required sta­tus code. In re­sponse, the client pays for ac­cess on-de­mand, and the server can let the client through to the re­quested con­tent.

EmDash has built-in sup­port for x402. This means any­one with an EmDash site can charge for ac­cess to their con­tent with­out re­quir­ing sub­scrip­tions and with zero en­gi­neer­ing work. All you need to do is con­fig­ure which con­tent should re­quire pay­ment, set how much to charge, and pro­vide a Wallet ad­dress. The re­quest/​re­sponse flow ends up look­ing like this:

Every EmDash site has a built-in busi­ness model for the AI era.

WordPress is not server­less: it re­quires pro­vi­sion­ing and man­ag­ing servers, scal­ing them up and down like a tra­di­tional web ap­pli­ca­tion. To max­i­mize per­for­mance, and to be able to han­dle traf­fic spikes, there’s no avoid­ing the need to pre-pro­vi­sion in­stances and run some amount of idle com­pute, or share re­sources in ways that limit per­for­mance. This is par­tic­u­larly true for sites with con­tent that must be server ren­dered and can­not be cached.

EmDash is dif­fer­ent: it’s built to run on server­less plat­forms, and make the most out of the v8 iso­late ar­chi­tec­ture of Cloudflare’s open source run­time work­erd. On an in­com­ing re­quest, the Workers run­time in­stantly spins up an iso­late to ex­e­cute code and serve a re­sponse. It scales back down to zero if there are no re­quests. And it only bills for CPU time (time spent do­ing ac­tual work).

You can run EmDash any­where, on any Node.js server — but on Cloudflare you can run mil­lions of in­stances of EmDash us­ing Cloudflare for Platforms that each in­stantly scale fully to zero or up to as many RPS as you need to han­dle, us­ing the ex­act same net­work and run­time that the biggest web­sites in the world rely on.

Beyond cost op­ti­miza­tions and per­for­mance ben­e­fits, we’ve bet on this ar­chi­tec­ture at Cloudflare in part be­cause we be­lieve in hav­ing low cost and free tiers, and that every­one should be able to build web­sites that scale. We’re ex­cited to help plat­forms ex­tend the ben­e­fits of this ar­chi­tec­ture to their own cus­tomers, both big and small.

EmDash is pow­ered by Astro, the web frame­work for con­tent-dri­ven web­sites. To cre­ate an EmDash theme, you cre­ate an Astro pro­ject that in­cludes:

A seed file: JSON that tells the CMS what con­tent types and fields to cre­ate

This makes cre­at­ing themes fa­mil­iar to fron­tend de­vel­op­ers who are in­creas­ingly choos­ing Astro, and to LLMs which are al­ready trained on Astro.

WordPress themes, though in­cred­i­bly flex­i­ble, op­er­ate with a lot of the same se­cu­rity risks as plu­g­ins, and the more pop­u­lar and com­mon­place your theme, the more of a tar­get it is. Themes run through in­te­grat­ing with func­tions.php which is an all-en­com­pass­ing ex­e­cu­tion en­vi­ron­ment, en­abling your theme to be both in­cred­i­bly pow­er­ful and po­ten­tially dan­ger­ous. EmDash themes, as with dy­namic plu­g­ins, turns this ex­pec­ta­tion on its head. Your theme can never per­form data­base op­er­a­tions.

The least fun part about work­ing with any CMS is do­ing the rote mi­gra­tion of con­tent: find­ing and re­plac­ing strings, mi­grat­ing cus­tom fields from one for­mat to an­other, re­nam­ing, re­order­ing and mov­ing things around. This is ei­ther bor­ing repet­i­tive work or re­quires one-off scripts and  “single-use” plu­g­ins and tools that are usu­ally nei­ther fun to write nor to use.

EmDash is de­signed to be man­aged pro­gram­mat­i­cally by your AI agents. It pro­vides the con­text and the tools that your agents need, in­clud­ing:

Agent Skills: Each EmDash in­stance in­cludes Agent Skills that de­scribe to your agent the ca­pa­bil­i­ties EmDash can pro­vide to plu­g­ins, the hooks that can trig­ger plu­g­ins, guid­ance on how to struc­ture a plu­gin, and even how to port legacy WordPress themes to EmDash na­tively. When you give an agent an EmDash code­base, EmDash pro­vides every­thing the agent needs to be able to cus­tomize your site in the way you need. EmDash CLI: The EmDash CLI en­ables your agent to in­ter­act pro­gram­mat­i­cally with your lo­cal or re­mote in­stance of EmDash. You can up­load me­dia, search for con­tent, cre­ate and man­age schemas, and do the same set of things you can do in the Admin UI.Built-in MCP Server: Every EmDash in­stance pro­vides its own re­mote Model Context Protocol (MCP) server, al­low­ing you to do the same set of things you can do in the Admin UI.

EmDash uses passkey-based au­then­ti­ca­tion by de­fault, mean­ing there are no pass­words to leak and no brute-force vec­tors to de­fend against. User man­age­ment in­cludes fa­mil­iar role-based ac­cess con­trol out of the box: ad­min­is­tra­tors, ed­i­tors, au­thors, and con­trib­u­tors, each scoped strictly to the ac­tions they need. Authentication is plug­gable, so you can set EmDash up to work with your SSO provider, and au­to­mat­i­cally pro­vi­sion ac­cess based on IdP meta­data.

You can im­port an ex­ist­ing WordPress site by ei­ther go­ing to WordPress ad­min and ex­port­ing a WXR file, or by in­stalling the EmDash Exporter plu­gin on a WordPress site, which con­fig­ures a se­cure end­point that is only ex­posed to you, and pro­tected by a WordPress Application Password you con­trol. Migrating con­tent takes just a few min­utes, and au­to­mat­i­cally works to bring any at­tached me­dia into EmDash’s me­dia li­brary.

Creating any cus­tom con­tent types on WordPress that are not a Post or a Page has meant in­stalling heavy plu­g­ins like Advanced Custom Fields, and squeez­ing the re­sult into a crowded WordPress posts table. EmDash does things dif­fer­ently: you can de­fine a schema di­rectly in the ad­min panel, which will cre­ate en­tirely new EmDash col­lec­tions for you, sep­a­rately or­dered in the data­base. On im­port, you can use the same ca­pa­bil­i­ties to take any cus­tom post types from WordPress, and cre­ate an EmDash con­tent type from it.

For be­spoke blocks, you can use the EmDash Block Kit Agent Skill to in­struct your agent of choice and build them for EmDash.

EmDash is v0.1.0 pre­view, and we’d love you to try it, give feed­back, and we wel­come con­tri­bu­tions to the EmDash GitHub repos­i­tory.

If you’re just play­ing around and want to first un­der­stand what’s pos­si­ble — try out the ad­min in­ter­face in the EmDash Playground.

To cre­ate a new EmDash site lo­cally, via the CLI, run:

Or you can do the same via the Cloudflare dash­board be­low:

We’re ex­cited to see what you build, and if you’re ac­tive in the WordPress com­mu­nity, as a host­ing plat­form, a plu­gin or theme au­thor, or oth­er­wise — we’d love to hear from you. Email us at [email protected], and tell us what you’d like to see from the EmDash pro­ject.

If you want to stay up to date with ma­jor EmDash de­vel­op­ments, you can leave your email ad­dress here.

Michael Larabel is the prin­ci­pal au­thor of Phoronix.com and founded the site in 2004 with a fo­cus on en­rich­ing the Linux hard­ware ex­pe­ri­ence. Michael has writ­ten more than 20,000 ar­ti­cles cov­er­ing the state of Linux hard­ware sup­port, Linux per­for­mance, graph­ics dri­vers, and other top­ics. Michael is also the lead de­vel­oper of the Phoronix Test Suite, Phoromatic, and OpenBenchmarking.org au­to­mated bench­mark­ing soft­ware. He can be fol­lowed via Twitter, LinkedIn, or con­tacted via MichaelLarabel.com.

Today Raspberry Pi an­nounced more price in­creases for all Pis with LPDDR4 RAM, along­side a ‘right-sized’ 3GB RAM Pi 4 for $83.75.

The price in­creases bring the 16GB Pi 5 up to $299.99.

Despite to­day’s date, this is not a joke.

I pub­lished a video go­ing over the state of the hob­by­ist ‘high end SBC’ mar­ket (4/8/16 GB mod­els in the cur­rent gen­er­a­tion), which I’ll em­bed be­low:

But if you’d like the tl;dr:

Unless the DRAM pric­ing sit­u­a­tion changes rad­i­cally, I think the hob­by­ist SBC mar­ket is dy­ing—or at least on life sup­port. And I don’t just mean Raspberry Pis, but all SBC ven­dors. LPDDR chips now ac­count for the ma­jor­ity of board cost from the ven­dors I’ve checked with.

Besides caus­ing a rad­i­cal re­duc­tion in new boards launched (Radxa seems to be the only ven­dor that had some ca­dence last year), the price in­creases for boards with greater than 4 GB of RAM have put those boards out of the reach of most hob­by­ists.

Even mini PCs, which for a time were a great deal, have risen to $250+ for 8 GB mod­els. Used PC are also more ex­pen­sive, es­pe­cially with more than 4 GB of RAM.

I de­sign most of my pro­jects so they can be repli­cated for less than $100. Learning is eas­ier on cheaper parts you won’t fret over too much when you break them. With prices go­ing up, this lim­its the types of pro­jects I take on.

I’m work­ing more with older SBCs and mi­cro­con­trollers now, and I think that’s the di­rec­tion many in the hob­by­ist space are go­ing.

Maybe, as Eben Upton says in Raspberry Pi’s post,

mem­ory prices won’t re­main at their cur­rent very high level in­def­i­nitely; the cir­cum­stances in which we find our­selves are chal­leng­ing, but in the fu­ture they will abate.

But I’m not sure how long we’ll have to wait, or if a hob­by­ist SBC mar­ket will ex­ist by the time the bub­ble bursts.

Lucky for Raspberry Pi, they have a thriv­ing mi­cro­con­troller ecosys­tem and in­dus­trial base to keep them go­ing. I fear smaller ven­dors won’t be able to go on like this for­ever.

Every time any of LinkedIn’s one bil­lion users vis­its linkedin.com, hid­den code searches their com­puter for in­stalled soft­ware, col­lects the re­sults, and trans­mits them to LinkedIn’s servers and to third-party com­pa­nies in­clud­ing an American-Israeli cy­ber­se­cu­rity firm.

The user is never asked. Never told. LinkedIn’s pri­vacy pol­icy does not men­tion it.

Because LinkedIn knows each user’s real name, em­ployer, and job ti­tle, it is not search­ing anony­mous vis­i­tors. It is search­ing iden­ti­fied peo­ple at iden­ti­fied com­pa­nies. Millions of com­pa­nies. Every day. All over the world.

Fairlinked e. V. is an as­so­ci­a­tion of com­mer­cial LinkedIn users. We rep­re­sent the pro­fes­sion­als who use LinkedIn, the busi­nesses that in­vest in and de­pend on the plat­form, and the tool­mak­ers who build prod­ucts for it.

BrowserGate is our in­ves­ti­ga­tion and cam­paign to doc­u­ment one of the largest cor­po­rate es­pi­onage and data breach scan­dals in dig­i­tal his­tory, to in­form the pub­lic and reg­u­la­tors, to col­lect ev­i­dence, and to raise funds for the le­gal pro­ceed­ings re­quired to stop it.

LinkedIn’s scan re­veals the re­li­gious be­liefs, po­lit­i­cal opin­ions, dis­abil­i­ties, and job search ac­tiv­ity of iden­ti­fied in­di­vid­u­als. LinkedIn scans for ex­ten­sions that iden­tify prac­tic­ing Muslims, ex­ten­sions that re­veal po­lit­i­cal ori­en­ta­tion, ex­ten­sions built for neu­ro­di­ver­gent users, and 509 job search tools that ex­pose who is se­cretly look­ing for work on the very plat­form where their cur­rent em­ployer can see their pro­file.

Under EU law, this cat­e­gory of data is not reg­u­lated. It is pro­hib­ited. LinkedIn has no con­sent, no dis­clo­sure, and no le­gal ba­sis. Its pri­vacy pol­icy does not men­tion any of this.

LinkedIn scans for over 200 prod­ucts that di­rectly com­pete with its own sales tools, in­clud­ing Apollo, Lusha, and ZoomInfo. Because LinkedIn knows each user’s em­ployer, it can map which com­pa­nies use which com­peti­tor prod­ucts. It is ex­tract­ing the cus­tomer lists of thou­sands of soft­ware com­pa­nies from their users’ browsers with­out any­one’s knowl­edge.

Then it uses what it finds. LinkedIn has al­ready sent en­force­ment threats to users of third-party tools, us­ing data ob­tained through this covert scan­ning to iden­tify its tar­gets.

In 2023, the EU des­ig­nated LinkedIn as a reg­u­lated gate­keeper un­der the Digital Markets Act and or­dered it to open its plat­form to third-party tools. LinkedIn’s re­sponse:

It pub­lished two re­stricted APIs and pre­sented them to the European Commission as com­pli­ance. Together, these APIs han­dle ap­prox­i­mately 0.07 calls per sec­ond. Meanwhile, LinkedIn al­ready op­er­ates an in­ter­nal API called Voyager that pow­ers every LinkedIn web and mo­bile prod­uct at 163,000 calls per sec­ond. In Microsoft’s 249-page com­pli­ance re­port to the EU, the word “API” ap­pears 533 times. “Voyager” ap­pears zero times.

At the same time, LinkedIn ex­panded its sur­veil­lance of the ex­act tools the reg­u­la­tion was de­signed to pro­tect. The scan list grew from roughly 461 prod­ucts in 2024 to over 6,000 by February 2026. The EU told LinkedIn to let third-party tools in. LinkedIn built a sur­veil­lance sys­tem to find and pun­ish every user of those tools.

LinkedIn loads an in­vis­i­ble track­ing el­e­ment from HUMAN Security (formerly PerimeterX), an American-Israeli cy­ber­se­cu­rity firm, zero pix­els wide, hid­den off-screen, that sets cook­ies on your browser with­out your knowl­edge. A sep­a­rate fin­ger­print­ing script runs from LinkedIn’s own servers. A third script from Google ex­e­cutes silently on every page load. All of it en­crypted. None of it dis­closed.

Microsoft has 33,000 em­ploy­ees and a $15 bil­lion le­gal bud­get. We have the ev­i­dence. What we need is peo­ple and fund­ing to hold them ac­count­able.

In 2023, the Swedish gov­ern­ment an­nounced that the coun­try’s schools would be go­ing back to ba­sics, em­pha­siz­ing skills such as read­ing and writ­ing, par­tic­u­larly in early grades. After mostly be­ing side­lined, phys­i­cal books are now be­ing rein­tro­duced into class­rooms, and stu­dents are learn­ing to write the old-fash­ioned way: by hand, with a pen­cil or pen, on sheets of pa­per. The Swedish gov­ern­ment also plans to make schools cell­phone-free through­out the coun­try.

Educational au­thor­i­ties have been in­vest­ing heav­ily. Last year alone, the ed­u­ca­tion min­istry al­lo­cated $83 mil­lion to pur­chase text­books and teach­ers’ guides. In a coun­try with about 11 mil­lion peo­ple, the aim is for every stu­dent to have a phys­i­cal text­book for each sub­ject. The gov­ern­ment also put $54 mil­lion to­wards the pur­chase of fic­tion and non-fic­tion books for stu­dents.

These moves rep­re­sent a dra­matic pivot from pre­vi­ous decades, dur­ing which Sweden — and many other na­tions — mov­ing away from phys­i­cal books in fa­vor of tablets and dig­i­tal re­sources in an ef­fort to pre­pare stu­dents for life in an on­line world. Perhaps un­sur­pris­ingly, the Nordic coun­try’s ef­forts have sparked a de­bate on the role of dig­i­tal tech­nol­ogy in ed­u­ca­tion, one that ex­tends well be­yond the coun­try’s bor­ders. U. S. par­ents in dis­tricts that have adopted dig­i­tal tech­nol­ogy to a great ex­tent may be won­der­ing if ed­u­ca­tors will re­verse course, too.

So why did Sweden pivot? In an email to Undark, Linda Fälth, a re­searcher in teacher ed­u­ca­tion at Linnaeus University, wrote that the “decision to rein­vest in phys­i­cal text­books and re­duce the em­pha­sis on dig­i­tal de­vices” was prompted by sev­eral fac­tors, in­clud­ing ques­tions around whether the dig­i­tal­iza­tion of class­rooms had been ev­i­dence-based. “There was also a broader cul­tural re­assess­ment,” Fälth wrote. “Sweden had po­si­tioned it­self as a fron­trun­ner in dig­i­tal ed­u­ca­tion, but over time con­cerns emerged about screen time, dis­trac­tion, re­duced deep read­ing, and the ero­sion of foun­da­tional skills such as sus­tained at­ten­tion and hand­writ­ing.”

Fälth noted that pro­po­nents of re­form be­lieve that “basic skills — es­pe­cially read­ing, writ­ing, and nu­mer­acy — must be firmly es­tab­lished first, and that phys­i­cal text­books are of­ten bet­ter suited for that pur­pose.”

Between 2000 and 2012, Swedish stu­dents’ scores on stan­dard­ized tests steadily de­clined in read­ing, math, and sci­ence. Though they re­cov­ered ground be­tween 2012 and 2018, those scores had dropped again by 2022.

Though it’s un­clear pre­cisely how much of the de­cline is due to dig­i­ti­za­tion, there is some ev­i­dence that ana­log teach­ing ma­te­ri­als for read­ing may be su­pe­rior to screen learn­ing. However, this ap­plies to ex­pos­i­tory as op­posed to nar­ra­tive texts. Narrative texts tell a story, whether fic­tion or non-fic­tion, while ex­pos­i­tory texts are de­signed to in­form, de­scribe, or ex­plain a topic in a log­i­cal, fac­tual man­ner.

Swedish of­fi­cials em­pha­size that dig­i­tal tech­nol­ogy is­n’t be­ing re­moved from schools al­to­gether. Rather, dig­i­tal aids “should only be in­tro­duced in teach­ing at an age when they en­cour­age, rather than hin­der, pupils’ learn­ing.” Achieving dig­i­tal com­pe­tence re­mains an im­por­tant ob­jec­tive, par­tic­u­larly in higher grades.

Historically, the tech­nol­ogy in­dus­try has pushed for more use of dig­i­tal learn­ing, see­ing it­self as a trans­former of ed­u­ca­tion. In the 1980s, Apple helped bring about the use of com­put­ers in schools. Then, start­ing with the use of the in­ter­net, and later in­te­grat­ing mo­bile de­vices, tech­nol­ogy re­shaped the ed­u­ca­tional land­scape. Education ex­perts sug­gest it can fos­ter a learn­ing ex­pe­ri­ence that is more in­ter­ac­tive, ac­ces­si­ble, and tai­lored to the needs of in­di­vid­ual stu­dents.

In the U. S., the trend na­tion­ally in re­cent years has been to­ward the use of in­creas­ingly so­phis­ti­cated meth­ods of dig­i­tal learn­ing, such as pro­vid­ing chil­dren with lap­tops or de­vices like the iPad. According to a sur­vey con­ducted by the EdWeek Research Center, part of the trade pub­li­ca­tion Education Week, 90 per­cent of school dis­trict lead­ers were pro­vid­ing de­vices for every mid­dle and high school stu­dent as of March 2021. More than 80 per­cent of school dis­trict lead­ers said the same was true for el­e­men­tary school stu­dents.

And now, tech­nol­ogy gi­ants such as Google, Microsoft, and OpenAI are urg­ing schools to teach lit­er­acy in ar­ti­fi­cial in­tel­li­gence. It’s be­lieved by some work­ing in ed­u­ca­tion that schools ought to pre­pare pupils for em­ploy­ers who ex­pect dig­i­tal flu­ency. This may in­deed be per­ti­nent in the age of AI. More than 50 per­cent of teens in America have used AI chat­bots for school­work, ac­cord­ing to a sur­vey con­ducted by the Pew Research Center.

According to a 2023 sur­vey, 30 per­cent of ed­u­ca­tors said their stu­dents spend at least half of their class­room read­ing time do­ing so dig­i­tally. But this may have draw­backs. Researchers sug­gest that read­ing on dig­i­tal dis­plays in­stead of pa­per may be more de­mand­ing men­tally, es­pe­cially for younger stu­dents. Studies have linked heavy dig­i­tal use to re­duced com­pre­hen­sion and mem­ory re­ten­tion as well as eye strain.

The lim­i­ta­tions of ed­u­ca­tional tech­nol­ogy be­came ap­par­ent dur­ing the Covid-19 pan­demic. When on­line learn­ing be­came the norm, ex­perts be­gan ques­tion­ing whether tech­nol­o­gy’s promises had ma­te­ri­al­ized. In a post on LinkedIn, Pam Kastner, a lit­er­acy con­sul­tant and ad­junct pro­fes­sor at Mount Saint Joseph University, sug­gests: “Technology is a tool, not a teacher.” She views the cog­ni­tive ar­chi­tec­ture for read­ing as be­ing built for print.

A well-known critic of the use of smart­phones and so­cial me­dia by chil­dren, Jonathan Haidt, posted in February: “Putting com­put­ers and tablets on stu­dents desks in K-12 may turn out to be among the costli­est mis­takes in the his­tory of ed­u­ca­tion”.

The U. S. spent $30 bil­lion in 2024 on lap­tops and tablets and other ed­u­ca­tional tech­nol­ogy, 10 times more than on text­books. Neuroscientist and ed­u­ca­tor Jared Cooney Horvath has lamented the heavy use of dig­i­tal de­vices in ed­u­ca­tion. He has said that Gen Z, per­sons born roughly be­tween 1997 and 2012 and known for grow­ing up with dig­i­tal tech­nol­ogy as an in­te­gral part of their lives, is the first gen­er­a­tion in mod­ern his­tory to score lower on cog­ni­tive mea­sures than the pre­vi­ous one. In January of this year, he told a Senate com­mit­tee that this has re­sulted in a gen­er­a­tion of chil­dren who are less cog­ni­tively ca­pa­ble than their par­ents.

Whether the U. S. will fol­low Sweden’s path re­mains to be seen. Naomi Baron, a pro­fes­sor emerita of lin­guis­tics at American University, told Undark she does­n’t see the U.S. turn­ing to Sweden for ad­vice. This is in part be­cause of fi­nan­cial in­cen­tives: “First, com­mer­cial text­book pub­lish­ers have been push­ing dig­i­tal ma­te­ri­als — heav­ily for fi­nan­cial rea­sons gen­er­ally ig­nor­ing the re­search com­par­ing com­pre­hen­sion, etc. with print vs. dig­i­tal read­ing.” Baron also wrote that “American ed­u­ca­tors them­selves are gen­er­ally un­aware of the now sub­stan­tial re­search lit­er­a­ture here, and in­stead fo­cus on sav­ing their stu­dents (or school dis­tricts) money.” Still, some American ed­u­ca­tors ap­pear to be aware that dig­i­tal tech­nol­ogy might be mak­ing ed­u­ca­tion worse. Teachers seem es­pe­cially con­cerned about the pos­si­ble detri­men­tal ef­fects of overuse of AI.

At the same time, some American par­ents have re­cently started form­ing net­works, teach­ing one an­other how to opt out of school-is­sued lap­tops and de­vices and back into phys­i­cal text­books, along with a re­ver­sion to pen or pen­cil and pa­per. Parents point to ev­i­dence show­ing bet­ter in­for­ma­tion re­ten­tion when pupils read it on pa­per. This re­ac­tion may re­flect a grow­ing back­lash to dig­i­tal tech­nol­ogy in ed­u­ca­tion, dri­ven by con­cerns about pos­si­bly ex­ces­sive screen time and po­ten­tial harms to youth, in­clud­ing pos­si­bly ad­dic­tive dis­trac­tions.

If U. S. ed­u­ca­tional lead­ers were to con­sult their Swedish col­leagues, the ad­vice they’d likely get is not to re­move dig­i­tal tech­nol­ogy whole cloth. “The goal is re­cal­i­bra­tion rather than re­ver­sal,” wrote Fälth. This was echoed in a state­ment sent to Undark by the Swedish Ministry of Education and Research: The “Swedish gov­ern­ment be­lieves that dig­i­tal­iza­tion is fun­da­men­tally im­por­tant and ben­e­fi­cial, but the use of dig­i­tal tools in schools must be car­ried out care­fully and thought­fully.”

In other words, the ob­jec­tive is not to re­ject dig­i­tal­iza­tion. It’s more nu­anced than that. The goal is to ju­di­ciously es­tab­lish bound­aries around tech­nol­o­gy’s se­lec­tive and se­quen­tial use over stages of a pupil’s ed­u­ca­tional de­vel­op­ment. This means in­tro­duc­ing dig­i­tal tech­nol­ogy at later ages af­ter ba­sic read­ing and other skills have been achieved.

Use this to de­tect changes in like­li­hoods of events, for in­stance, to iso­late a com­mit where a slightly flaky test be­came very flaky.

You don’t need to know the like­li­hoods (although you can pro­vide pri­ors), just that some­thing has changed at some point in some di­rec­tion

git_bayesect uses Bayesian in­fer­ence to iden­tify the com­mit in­tro­duc­ing a change, with com­mit se­lec­tion per­formed via greedy min­imi­sa­tion of ex­pected en­tropy, and us­ing a Beta-Bernoulli con­ju­gacy trick while cal­cu­lat­ing pos­te­rior prob­a­bil­i­ties to make han­dling un­known fail­ure rates tractable.

See https://​hauntsan­inja.github.io/​git_bayesect.html for a write up.

Record an ob­ser­va­tion on the cur­rent com­mit:

Check the over­all sta­tus of the bi­sec­tion:

Set the prior for a given com­mit:

Set prior for all com­mits based on file­names:

Set prior for all com­mits based on the text in the com­mit mes­sage + diff:

Get a log of com­mands to let you re­con­struct the state:

Run the bi­sec­tion au­to­mat­i­cally us­ing a com­mand to make ob­ser­va­tions:

Checkout the best com­m­mit to test:

This repos­i­tory con­tains a lit­tle demo, in case you’d like to play around:

In mem­ory of the 72,000+ Palestinians killed in the Israeli geno­cide in Gaza.

Today…Overcast. Much cooler. High 46F. Winds ENE at 10 to 15 mph. Tonight…Cloudy. Low near 40F. Winds ESE at 5 to 10 mph.To­mor­row…Cloudy skies early will be­come partly cloudy later in the day. High 67F. Winds SSW at 10 to 15 mph.Retro­Cast Now be­gins soon for your lo­ca­tion