[{"data":1,"prerenderedAt":4187},["ShallowReactive",2],{"page-\u002Fbyodt-cloud\u002Foperations":3,"navigation":3865},{"id":4,"title":5,"body":6,"description":3851,"extension":3852,"meta":3853,"navigation":3860,"path":3861,"seo":3862,"stem":3863,"__hash__":3864},"docs\u002F02.byodt-cloud\u002F03.operations.md","Operating the BYODt Deployment",{"type":7,"value":8,"toc":3792},"minimark",[9,13,25,32,35,40,56,331,365,391,400,407,415,417,421,437,442,451,481,485,519,525,573,577,585,624,643,647,651,660,694,703,710,714,739,746,750,759,765,786,801,805,814,817,819,823,833,836,845,891,906,908,912,916,923,950,961,973,977,997,1000,1006,1009,1015,1027,1037,1053,1073,1081,1085,1095,1099,1114,1120,1165,1168,1174,1184,1186,1190,1197,1200,1204,1213,1216,1222,1225,1229,1244,1266,1272,1276,1290,1294,1303,1317,1334,1338,1352,1356,1366,1368,1371,1384,1418,1424,1427,1442,1449,1469,1493,1498,1536,1540,1543,1780,1783,1789,1793,1810,1927,1936,1942,1958,1961,1964,2048,2051,2057,2072,2122,2140,2144,2156,2165,2174,2177,2180,2189,2196,2262,2274,2280,2283,2289,2295,2301,2318,2325,2372,2383,2387,2393,2399,2470,2474,2477,2503,2506,2509,2521,2527,2533,2551,2574,2596,2599,2610,2626,2643,2649,2658,2667,2673,2693,2699,2797,2800,2815,2837,2914,2936,2939,2947,2969,2974,2983,2986,2990,3001,3021,3025,3028,3043,3067,3076,3083,3092,3127,3159,3195,3206,3210,3219,3233,3246,3250,3258,3276,3281,3297,3457,3463,3500,3515,3528,3569,3584,3593,3595,3599,3603,3612,3629,3640,3649,3653,3677,3679,3683,3686,3706,3726,3752,3763,3765,3769,3788],[10,11,5],"h1",{"id":12},"operating-the-byodt-deployment",[14,15,16,20,21,24],"p",{},[17,18,19],"code",{},"byodt"," is the deployment's control script and the whole operator interface. It wraps your container engine's ",[17,22,23],{},"compose"," command, carries the configuration and secret files every operation needs, and gives the common tasks plain names.",[14,26,27,28,31],{},"Run it from the bundle directory. It always operates on the bundle it lives in, so ",[17,29,30],{},"\u002Fpath\u002Fto\u002Fbyodt-X.Y.Z\u002Fbyodt status"," works from anywhere.",[33,34],"hr",{},[36,37,39],"h2",{"id":38},"command-reference","Command reference",[41,42,47],"pre",{"className":43,"code":44,"language":45,"meta":46,"style":46},"language-sh shiki shiki-themes github-light github-dark-dimmed",".\u002Fbyodt help\n","sh","",[17,48,49],{"__ignoreMap":46},[50,51,54],"span",{"class":52,"line":53},"line",1,[50,55,44],{},[57,58,64],"div",{"className":59,"tabIndex":61,"role":62,"ariaLabel":63},[60],"table-frame",0,"region","Table: Command reference",[65,66,67,80],"table",{},[68,69,70],"thead",{},[71,72,73,77],"tr",{},[74,75,76],"th",{},"Command",[74,78,79],{},"What it does",[81,82,83,106,116,134,144,154,164,174,188,202,216,226,240,250,260,270,280,294,308,318],"tbody",{},[71,84,85,91],{},[86,87,88],"td",{},[17,89,90],{},".\u002Fbyodt setup",[86,92,93,94,97,98,105],{},"The first run: ask for the settings, show the third-party notice, and write ",[17,95,96],{},".env",". See ",[99,100,102,103],"a",{"href":101},"\u002Fbyodt-cloud\u002Finstallation#set-up-with-byodt-setup","Installation → Set up with ",[17,104,90],{},".",[71,107,108,113],{},[86,109,110],{},[17,111,112],{},".\u002Fbyodt up",[86,114,115],{},"Start the deployment, and apply configuration changes. Performs first-run setup if needed.",[71,117,118,123],{},[86,119,120],{},[17,121,122],{},".\u002Fbyodt down [--take-over]",[86,124,125,126,129,130,105],{},"Stop the deployment. Data is kept. ",[17,127,128],{},"--take-over",": see ",[99,131,133],{"href":132},"#a-deployment-in-another-folder","A deployment in another folder",[71,135,136,141],{},[86,137,138],{},[17,139,140],{},".\u002Fbyodt restart [service]",[86,142,143],{},"Recreate the containers to apply a change — all of them, or one named service.",[71,145,146,151],{},[86,147,148],{},[17,149,150],{},".\u002Fbyodt status",[86,152,153],{},"Show the state of every service.",[71,155,156,161],{},[86,157,158],{},[17,159,160],{},".\u002Fbyodt logs [service]",[86,162,163],{},"Follow the logs — all services, or one.",[71,165,166,171],{},[86,167,168],{},[17,169,170],{},".\u002Fbyodt update",[86,172,173],{},"Pull the pinned images and apply them.",[71,175,176,181],{},[86,177,178],{},[17,179,180],{},".\u002Fbyodt upgrade [VERSION]",[86,182,183,184,105],{},"Move to a newer release, the latest by default. See ",[99,185,187],{"href":186},"#upgrading-to-a-new-release","Upgrading to a new release",[71,189,190,195],{},[86,191,192],{},[17,193,194],{},".\u002Fbyodt models pull",[86,196,197,198,201],{},"Download and verify the embedding model's weights into ",[17,199,200],{},"data\u002Fmodels"," ahead of the first start.",[71,203,204,209],{},[86,205,206],{},[17,207,208],{},".\u002Fbyodt backup [dir]",[86,210,211,212,215],{},"Back up the graph and copy it out. Defaults to ",[17,213,214],{},"backups\u002F",". On Neo4j the database stops while it is dumped.",[71,217,218,223],{},[86,219,220],{},[17,221,222],{},".\u002Fbyodt restore \u003Cfile>",[86,224,225],{},"Replace the graph from a backup. Asks you to confirm.",[71,227,228,233],{},[86,229,230],{},[17,231,232],{},".\u002Fbyodt bootstrap",[86,234,235,236,239],{},"First-run setup only: directories, database password, mode layer. ",[17,237,238],{},"up"," does this for you.",[71,241,242,247],{},[86,243,244],{},[17,245,246],{},".\u002Fbyodt destroy [--take-over]",[86,248,249],{},"Remove the containers and the network. Data on disk is kept.",[71,251,252,257],{},[86,253,254],{},[17,255,256],{},".\u002Fbyodt console",[86,258,259],{},"Print the console URL, and open it where the platform supports that.",[71,261,262,267],{},[86,263,264],{},[17,265,266],{},".\u002Fbyodt tls generate [hostname]",[86,268,269],{},"Generate a self-signed front-door certificate.",[71,271,272,277],{},[86,273,274],{},[17,275,276],{},".\u002Fbyodt tls status",[86,278,279],{},"Show the installed certificate, or report that there is none.",[71,281,282,287],{},[86,283,284],{},[17,285,286],{},".\u002Fbyodt notice [--all]",[86,288,289,290,293],{},"Print the third-party notice, without asking. ",[17,291,292],{},"--all",": for both databases.",[71,295,296,301],{},[86,297,298],{},[17,299,300],{},".\u002Fbyodt acknowledge",[86,302,303,304,105],{},"Show the third-party notice and record your confirmation. See ",[99,305,307],{"href":306},"\u002Fbyodt-cloud\u002Finstallation#the-third-party-notice","Installation → The third-party notice",[71,309,310,315],{},[86,311,312],{},[17,313,314],{},".\u002Fbyodt version",[86,316,317],{},"Show the control script's version and the pinned release set.",[71,319,320,325],{},[86,321,322],{},[17,323,324],{},".\u002Fbyodt compose [args]",[86,326,327,328,330],{},"Run your engine's ",[17,329,23],{}," with this bundle's configuration and compose files.",[14,332,333,334,337,338,337,341,337,344,337,347,337,350,337,353,356,357,360,361,364],{},"Several commands accept a familiar alias: ",[17,335,336],{},"start",", ",[17,339,340],{},"stop",[17,342,343],{},"ps",[17,345,346],{},"pull",[17,348,349],{},"init",[17,351,352],{},"nuke",[17,354,355],{},"open",". They do exactly what the primary name does. ",[17,358,359],{},"upgrade"," is no longer an alias of ",[17,362,363],{},"update",": it is a command of its own.",[14,366,367,337,370,337,372,337,374,337,376,337,379,382,383,386,387,390],{},[17,368,369],{},"setup",[17,371,238],{},[17,373,363],{},[17,375,359],{},[17,377,378],{},"restart",[17,380,381],{},"models pull"," and ",[17,384,385],{},"acknowledge"," take ",[17,388,389],{},"--yes",": ask nothing, and count the third-party notice as confirmed. It is printed either way.",[14,392,393,395,396,399],{},[17,394,19],{}," names itself in its messages the way you ran it: ",[17,397,398],{},".\u002Fbyodt …"," from the bundle directory, or the path you used.",[14,401,402,406],{},[403,404,405],"strong",{},"Service names",", for the commands that take one:",[41,408,413],{"className":409,"code":411,"language":412},[410],"language-text","db   console-init   platform   proxy   console\n","text",[17,414,411],{"__ignoreMap":46},[33,416],{},[36,418,420],{"id":419},"starting-and-stopping","Starting and stopping",[41,422,424],{"className":43,"code":423,"language":45,"meta":46,"style":46},".\u002Fbyodt up        # start (and apply any configuration change)\n.\u002Fbyodt down      # stop; everything on disk is kept\n",[17,425,426,431],{"__ignoreMap":46},[50,427,428],{"class":52,"line":53},[50,429,430],{},".\u002Fbyodt up        # start (and apply any configuration change)\n",[50,432,434],{"class":52,"line":433},2,[50,435,436],{},".\u002Fbyodt down      # stop; everything on disk is kept\n",[14,438,439,441],{},[17,440,238],{}," is safe to run at any time. On a fresh bundle it performs first-run setup; on a running deployment with nothing changed it does nothing; after an edit it recreates whatever the change affected.",[14,443,444,447,448,450],{},[17,445,446],{},"down"," stops and removes the containers and leaves your data, configuration, and images alone. ",[17,449,112],{}," brings the deployment back exactly as it was.",[452,453,454],"blockquote",{},[14,455,456,459,460,382,462,465,466,337,469,472,473,476,477,480],{},[403,457,458],{},"Flags that delete data are refused."," ",[17,461,446],{},[17,463,464],{},"destroy"," reject ",[17,467,468],{},"-v",[17,470,471],{},"--volumes",", and ",[17,474,475],{},"--rmi"," rather than passing them through, so a reflexive ",[17,478,479],{},"down -v"," cannot wipe a graph stored in a named volume. Safe flags still work.",[482,483,133],"h3",{"id":484},"a-deployment-in-another-folder",[14,486,487,488,491,492,494,495,337,497,337,499,337,501,337,503,337,505,337,507,337,510,337,513,382,515,518],{},"Every bundle's deployment has the same compose project name, ",[17,489,490],{},"dethernety",", so two bundle folders on one host would act on the same containers, and, with a named volume, on the same graph. ",[17,493,19],{}," therefore checks, before ",[17,496,238],{},[17,498,363],{},[17,500,378],{},[17,502,446],{},[17,504,340],{},[17,506,464],{},[17,508,509],{},"backup",[17,511,512],{},"restore",[17,514,359],{},[17,516,517],{},"setup --start"," act, that no other folder runs or ran this project. When one does, it names that folder and changes nothing:",[41,520,523],{"className":521,"code":522,"language":412},[410],"error: this bundle's compose project is already used by another directory:\n    \u002Fhome\u002Fyou\u002Fdethernety-old\nRunning this here would act on its containers. Upgrade that deployment instead ('.\u002Fbyodt upgrade' in it), or\nstop it there ('.\u002Fbyodt down'). If this deployment was moved here from that directory, run '.\u002Fbyodt down --take-over'\nhere once to remove the old containers, then start it here.\n",[17,524,522],{"__ignoreMap":46},[526,527,528,539],"ul",{},[529,530,531,534,535,538],"li",{},[403,532,533],{},"Two deployments, on purpose:"," only one can run at a time. Stop the other one in its own folder (",[17,536,537],{},".\u002Fbyodt down"," there), then start this one.",[529,540,541,544,545,560,563,566,567,569,570,572],{},[403,542,543],{},"You moved the deployment here"," (copied or renamed its folder): the old containers still carry the old folder's path. Remove them once from here, then start here:",[41,546,548],{"className":43,"code":547,"language":45,"meta":46,"style":46},".\u002Fbyodt down --take-over\n.\u002Fbyodt up\n",[17,549,550,555],{"__ignoreMap":46},[50,551,552],{"class":52,"line":53},[50,553,554],{},".\u002Fbyodt down --take-over\n",[50,556,557],{"class":52,"line":433},[50,558,559],{},".\u002Fbyodt up\n",[561,562],"br",{},[17,564,565],{},"destroy --take-over"," does the same and prints the wipe commands, as ",[17,568,464],{}," does. ",[17,571,128],{}," removes the project's containers whichever folder started them, so do not use it while another deployment you want to keep is running.",[36,574,576],{"id":575},"applying-a-change","Applying a change",[14,578,579,580,584],{},"Which command applies a change depends on what you changed. The full table is in ",[99,581,583],{"href":582},"\u002Fbyodt-cloud\u002Fconfiguration#how-to-apply-a-change","Configuration → How to apply a change",". In short:",[41,586,588],{"className":43,"code":587,"language":45,"meta":46,"style":46},".\u002Fbyodt up                    # after editing .env, or the proxy login in .env.secrets\n.\u002Fbyodt restart               # after connecting or disconnecting the cloud\n.\u002Fbyodt restart platform      # after mounting or unmounting a content module, or updating the knowledge graph\n.\u002Fbyodt restart proxy         # after adding, replacing, or removing a certificate\n.\u002Fbyodt restart db            # after changing DB_DATA, SNAPSHOT_INTERVAL_SEC, or a NEO4J_DATA\u002F_HEAP_SIZE\u002F_PAGECACHE_SIZE\n.\u002Fbyodt restart platform console   # after replacing proxy-ca\u002Fproxy-ca.pem, the outbound proxy's CA\n",[17,589,590,595,600,606,612,618],{"__ignoreMap":46},[50,591,592],{"class":52,"line":53},[50,593,594],{},".\u002Fbyodt up                    # after editing .env, or the proxy login in .env.secrets\n",[50,596,597],{"class":52,"line":433},[50,598,599],{},".\u002Fbyodt restart               # after connecting or disconnecting the cloud\n",[50,601,603],{"class":52,"line":602},3,[50,604,605],{},".\u002Fbyodt restart platform      # after mounting or unmounting a content module, or updating the knowledge graph\n",[50,607,609],{"class":52,"line":608},4,[50,610,611],{},".\u002Fbyodt restart proxy         # after adding, replacing, or removing a certificate\n",[50,613,615],{"class":52,"line":614},5,[50,616,617],{},".\u002Fbyodt restart db            # after changing DB_DATA, SNAPSHOT_INTERVAL_SEC, or a NEO4J_DATA\u002F_HEAP_SIZE\u002F_PAGECACHE_SIZE\n",[50,619,621],{"class":52,"line":620},6,[50,622,623],{},".\u002Fbyodt restart platform console   # after replacing proxy-ca\u002Fproxy-ca.pem, the outbound proxy's CA\n",[14,625,626,627,630,631,634,635,637,638,642],{},"Naming a service recreates only that service, not its dependencies — ",[17,628,629],{},".\u002Fbyodt restart proxy"," re-reads the front-door configuration without bouncing the database underneath it. The service called ",[17,632,633],{},"proxy"," is the front door; the outbound proxy, if you use one, is set in ",[17,636,96],{}," (see ",[99,639,641],{"href":640},"\u002Fbyodt-cloud\u002Fconfiguration#outbound-proxy","Configuration → Outbound proxy",").",[36,644,646],{"id":645},"inspecting-the-deployment","Inspecting the deployment",[482,648,650],{"id":649},"service-state","Service state",[41,652,654],{"className":43,"code":653,"language":45,"meta":46,"style":46},".\u002Fbyodt status\n",[17,655,656],{"__ignoreMap":46},[50,657,658],{"class":52,"line":53},[50,659,653],{},[14,661,662,663,337,666,337,669,472,671,674,675,337,677,472,679,681,682,685,686,689,690,693],{},"Shows every running service with its state and health. A healthy deployment shows ",[17,664,665],{},"db",[17,667,668],{},"platform",[17,670,633],{},[17,672,673],{},"console"," running, with ",[17,676,665],{},[17,678,668],{},[17,680,633],{}," healthy. ",[17,683,684],{},"console-init"," is a one-shot, so plain ",[17,687,688],{},"status"," does not list it once it has exited; add ",[17,691,692],{},"-a"," to see it:",[41,695,697],{"className":43,"code":696,"language":45,"meta":46,"style":46},".\u002Fbyodt status -a\n",[17,698,699],{"__ignoreMap":46},[50,700,701],{"class":52,"line":53},[50,702,696],{},[14,704,705,706,709],{},"Its line should read ",[17,707,708],{},"Exited (0)"," — exiting is what success looks like.",[482,711,713],{"id":712},"logs","Logs",[41,715,717],{"className":43,"code":716,"language":45,"meta":46,"style":46},".\u002Fbyodt logs                  # everything, interleaved\n.\u002Fbyodt logs platform         # one service\n.\u002Fbyodt logs console-init     # the first-run one-shot: schema, modules, ingest\n.\u002Fbyodt logs db\n",[17,718,719,724,729,734],{"__ignoreMap":46},[50,720,721],{"class":52,"line":53},[50,722,723],{},".\u002Fbyodt logs                  # everything, interleaved\n",[50,725,726],{"class":52,"line":433},[50,727,728],{},".\u002Fbyodt logs platform         # one service\n",[50,730,731],{"class":52,"line":602},[50,732,733],{},".\u002Fbyodt logs console-init     # the first-run one-shot: schema, modules, ingest\n",[50,735,736],{"class":52,"line":608},[50,737,738],{},".\u002Fbyodt logs db\n",[14,740,741,742,745],{},"Logs are followed. ",[17,743,744],{},"Ctrl-C"," stops the stream and nothing else.",[482,747,749],{"id":748},"the-pinned-release","The pinned release",[41,751,753],{"className":43,"code":752,"language":45,"meta":46,"style":46},".\u002Fbyodt version\n",[17,754,755],{"__ignoreMap":46},[50,756,757],{"class":52,"line":53},[50,758,752],{},[41,760,763],{"className":761,"code":762,"language":412},[410],"byodt 1.4.0\nPinned release (from .env):\n  PLATFORM_VERSION=X.Y.Z\n  DB_IMAGE=…\n  PROXY_IMAGE=…\n  DB_ENGINE=memgraph\n",[17,764,762],{"__ignoreMap":46},[14,766,767,768,770,771,773,774,777,778,780,781,783,784,105],{},"The first line is the control script's own version, which is independent of the platform release. The rest is exactly what this deployment is pinned to, in the order the lines appear in ",[17,769,96],{},". On Neo4j ",[17,772,19],{}," records ",[17,775,776],{},"NEO4J_IMAGE"," in ",[17,779,96],{}," on the first run; before that, it adds the image ",[17,782,19],{}," would use, marked as the tested image, not set in ",[17,785,96],{},[14,787,788,789,792,793,796,797,800],{},"The console image is not listed, because it follows ",[17,790,791],{},"PLATFORM_VERSION"," rather than being pinned separately. It appears here only if you have uncommented ",[17,794,795],{},"CONSOLE_IMAGE"," to point at a mirror. A leftover ",[17,798,799],{},"OLLAMA_IMAGE"," line from an older release is not listed: this bundle no longer uses it.",[482,802,804],{"id":803},"the-console","The console",[41,806,808],{"className":43,"code":807,"language":45,"meta":46,"style":46},".\u002Fbyodt console\n",[17,809,810],{"__ignoreMap":46},[50,811,812],{"class":52,"line":53},[50,813,807],{},[14,815,816],{},"Prints the console address and opens it where the platform supports that. The console reports the deployment's health, what the one-shot placed, whether the platform registered it, and whether any change is waiting to be applied. It runs outside the request path and has no dependency on the rest of the deployment, so it can still report while the platform is down.",[33,818],{},[36,820,822],{"id":821},"the-embedding-model","The embedding model",[14,824,825,826,829,830,832],{},"The platform embeds in process with its built-in model, EmbeddingGemma 300m (",[17,827,828],{},"embeddinggemma-300m-retrieval-v1","). Its weights (about 1.26 GB) live in ",[17,831,200],{},". The platform downloads them once from Hugging Face, on its first start, and verifies each file's sha256; every later start loads them from disk.",[14,834,835],{},"To download them ahead of a start — on a fresh install, or before an upgrade — run:",[41,837,839],{"className":43,"code":838,"language":45,"meta":46,"style":46},".\u002Fbyodt models pull\n",[17,840,841],{"__ignoreMap":46},[50,842,843],{"class":52,"line":53},[50,844,838],{},[14,846,847,848,854,855,858,859,861,862,864,865,337,868,870,871,382,873,875,876,879,880,883,884,887,888,890],{},"It runs the platform's own download code in a one-off platform container, with no database, so the stack can be up or down. It prints the model's size and its licence (the ",[99,849,853],{"href":850,"rel":851},"https:\u002F\u002Fai.google.dev\u002Fgemma\u002Fterms",[852],"nofollow","Gemma Terms of Use","), downloads only what is missing or fails verification, and ends with ",[17,856,857],{},"Ready"," once the weights are in place. ",[17,860,744],{}," stops it without keeping a partial file; run it again to continue. If ",[17,863,96],{}," still sets ",[17,866,867],{},"EMBEDDING_MODEL=embeddinggemma",[17,869,19],{}," stops it first with its own check, the one ",[17,872,112],{},[17,874,170],{}," run, and tells you to remove the line; any other value the platform would not run is refused by the download code, with the platform's message. It exits ",[17,877,878],{},"0"," once the weights are in place, ",[17,881,882],{},"1"," on a refusal or failure, and ",[17,885,886],{},"130"," when stopped. Behind an outbound proxy it downloads through the proxy ",[17,889,96],{}," names, with the platform's login and CA, so it is also the quickest test of that setting; a failure names the host that failed.",[14,892,893,894,897,898,901,902,105],{},"While the platform is downloading or loading the model, ",[17,895,896],{},"\u002Fhealth"," reports ",[17,899,900],{},"degraded"," and class and technique matching uses names; see ",[99,903,905],{"href":904},"\u002Fbyodt-cloud\u002Ftroubleshooting#matching-uses-names-after-a-start","Troubleshooting → Matching uses names after a start",[33,907],{},[36,909,911],{"id":910},"backing-up-and-restoring-the-graph","Backing up and restoring the graph",[482,913,915],{"id":914},"what-a-backup-is","What a backup is",[14,917,918,919,922],{},"What ",[17,920,921],{},".\u002Fbyodt backup"," does depends on the database engine:",[526,924,925,931],{},[529,926,927,930],{},[403,928,929],{},"Memgraph:"," it asks the database for a fresh, consistent snapshot — taken hot, with no downtime — and copies that file out of the container to a durable location.",[529,932,933,936,937,939,940,942,943,946,947,949],{},[403,934,935],{},"Neo4j:"," Neo4j Community dumps an offline database only. ",[17,938,19],{}," makes a private working directory for the dump, stops ",[17,941,665],{},", dumps the graph with ",[17,944,945],{},"neo4j-admin"," in a one-off container, copies the dump out, removes the directory, and starts ",[17,948,665],{}," again — also when the stop or the dump fails. The platform loses its database connection meanwhile; plan the backup for a quiet moment.",[14,951,952,953,956,957,960],{},"A backup is the ",[403,954,955],{},"graph only",": every model, finding, control, and the reference corpus. It does ",[403,958,959],{},"not"," contain the database password, which is separate state. Two consequences:",[526,962,963,970],{},[529,964,965,966,969],{},"You can move it between machines, and it restores cleanly onto any deployment ",[403,967,968],{},"of the same version and engine",". Each engine refuses the other's backup file.",[529,971,972],{},"It is not a secret-bearing file in the credential sense — but it is your entire threat-modelling estate, so keep it private.",[482,974,976],{"id":975},"taking-one","Taking one",[41,978,980],{"className":43,"code":979,"language":45,"meta":46,"style":46},".\u002Fbyodt backup                    # Memgraph → backups\u002Fbyodt-snapshot-\u003Cversion>-\u003Ctimestamp>.snapshot\n                                  # Neo4j    → backups\u002Fbyodt-dump-\u003Cversion>-\u003Ctimestamp>.dump\n.\u002Fbyodt backup \u002Fpath\u002Fto\u002Farchive   # write somewhere else\n",[17,981,982,987,992],{"__ignoreMap":46},[50,983,984],{"class":52,"line":53},[50,985,986],{},".\u002Fbyodt backup                    # Memgraph → backups\u002Fbyodt-snapshot-\u003Cversion>-\u003Ctimestamp>.snapshot\n",[50,988,989],{"class":52,"line":433},[50,990,991],{},"                                  # Neo4j    → backups\u002Fbyodt-dump-\u003Cversion>-\u003Ctimestamp>.dump\n",[50,993,994],{"class":52,"line":602},[50,995,996],{},".\u002Fbyodt backup \u002Fpath\u002Fto\u002Farchive   # write somewhere else\n",[14,998,999],{},"On Memgraph:",[41,1001,1004],{"className":1002,"code":1003,"language":412},[410],"==> Requesting a snapshot…\n==> Backup written: backups\u002Fbyodt-snapshot-X.Y.Z-20260814-101112.snapshot (12M)\n==> The whole graph is in here (no password) — keep it private and copy it off-box so it survives losing this machine.\n",[17,1005,1003],{"__ignoreMap":46},[14,1007,1008],{},"On Neo4j:",[41,1010,1013],{"className":1011,"code":1012,"language":412},[410],"==> Stopping the database — Neo4j Community dumps an offline database…\n==> Dumping the graph…\n    …neo4j-admin output…\n==> Starting the database again…\n==> Backup written: backups\u002Fbyodt-dump-X.Y.Z-20260814-101112.dump (12M)\n==> The whole graph is in here (no password) — keep it private and copy it off-box so it survives losing this machine.\n",[17,1014,1012],{"__ignoreMap":46},[14,1016,1017,1018,1020,1021,1023,1024],{},"The filename records the version the backup was taken on, which is what lets ",[17,1019,512],{}," warn you about a mismatch later. The file is readable by you only: a Memgraph snapshot is narrowed to you once it is copied out, and a Neo4j dump is created that way. On a file system that does not keep modes, ",[17,1022,19],{}," warns: ",[17,1025,1026],{},"Could not make … private to you (its file system may not keep modes); keep it where only you can read it.",[14,1028,1029,1030,382,1032,1034,1035,105],{},"The database must be running and reachable when you start a backup — the command probes it first and stops with a clear message if it is not. ",[17,1031,509],{},[17,1033,512],{}," also refuse to act on a deployment another folder runs; see ",[99,1036,133],{"href":132},[14,1038,1039,1040,382,1042,1044,1045,1048,1049,1052],{},"On Memgraph under Podman, ",[17,1041,509],{},[17,1043,512],{}," copy the snapshot with ",[17,1046,1047],{},"podman cp",", so they work with ",[17,1050,1051],{},"podman-compose"," as with Docker Compose.",[14,1054,1055,1056,1058,1059,1062,1063,1066,1067,1069,1070,105],{},"On Neo4j the dump goes through a private working directory that ",[17,1057,19],{}," makes in the bundle root for each backup or restore — ",[17,1060,1061],{},".byodt-dump.XXXXXX",", mode ",[17,1064,1065],{},"0700",", owned by you — and mounts into the one-off ",[17,1068,945],{}," container only. It is removed when the command ends, also on failure. The dump never passes through ",[17,1071,1072],{},"data\u002F",[452,1074,1075],{},[14,1076,1077,1080],{},[403,1078,1079],{},"Copy backups off this machine."," A backup sitting next to the data it protects is lost with the machine. This is the single most valuable thing on this page.",[482,1082,1084],{"id":1083},"automatic-snapshots-are-not-backups","Automatic snapshots are not backups",[14,1086,1087,1088,1091,1092,1094],{},"Memgraph also writes in-place snapshots every ",[17,1089,1090],{},"SNAPSHOT_INTERVAL_SEC"," seconds (default 300) for crash recovery. They live inside the data directory and are pruned over time by the database's own retention. They protect you from a crash; they do not protect you from losing the disk, the directory, or the machine. Use ",[17,1093,921],{}," for anything you want to keep.",[482,1096,1098],{"id":1097},"restoring","Restoring",[41,1100,1102],{"className":43,"code":1101,"language":45,"meta":46,"style":46},".\u002Fbyodt restore backups\u002Fbyodt-snapshot-X.Y.Z-20260814-101112.snapshot   # Memgraph\n.\u002Fbyodt restore backups\u002Fbyodt-dump-X.Y.Z-20260814-101112.dump           # Neo4j\n",[17,1103,1104,1109],{"__ignoreMap":46},[50,1105,1106],{"class":52,"line":53},[50,1107,1108],{},".\u002Fbyodt restore backups\u002Fbyodt-snapshot-X.Y.Z-20260814-101112.snapshot   # Memgraph\n",[50,1110,1111],{"class":52,"line":433},[50,1112,1113],{},".\u002Fbyodt restore backups\u002Fbyodt-dump-X.Y.Z-20260814-101112.dump           # Neo4j\n",[14,1115,1116,1119],{},[403,1117,1118],{},"This replaces the current graph."," All current graph data is cleared, and the backup takes its place. The command:",[1121,1122,1123,1134,1137,1143,1150],"ol",{},[529,1124,1125,1126,1129,1130,1133],{},"Refuses a backup made by the other engine: a ",[17,1127,1128],{},".dump"," on Memgraph, a ",[17,1131,1132],{},".snapshot"," on Neo4j.",[529,1135,1136],{},"Warns first if the filename says the backup was taken on a different version than this deployment runs — a backup may not load across versions.",[529,1138,1139,1140,1142],{},"Warns you that the current graph will be cleared, and asks you to type ",[17,1141,512],{}," to confirm. Anything else aborts and changes nothing.",[529,1144,1145,1146,1149],{},"On ",[403,1147,1148],{},"Memgraph",", requires the database to be running, stages the file into the database container, and applies it.",[529,1151,1145,1152,1155,1156,1158,1159,1161,1162,1164],{},[403,1153,1154],{},"Neo4j",", copies the file into a private working directory (as for a backup), stops ",[17,1157,665],{},", loads the dump with ",[17,1160,945],{}," in a one-off container that mounts the directory read-only, removes the directory, and starts ",[17,1163,665],{}," again — also when the load fails. The platform loses its database connection meanwhile.",[14,1166,1167],{},"Your configuration and the database password are untouched, so the restored graph opens with this deployment's own credentials.",[41,1169,1172],{"className":1170,"code":1171,"language":412},[410],"==> Restore complete. If the app still shows old or empty data, run '.\u002Fbyodt restart platform'.\n",[17,1173,1171],{"__ignoreMap":46},[14,1175,1176,1177,1180,1181,1183],{},"On Memgraph, if a failure occurs partway, the current graph is left unchanged and the command says so. On Neo4j the load replaces the graph, so a failed load may already have removed the current one: the command stops with ",[17,1178,1179],{},"neo4j-admin could not load the dump — see its output above. The load replaces the graph, so the current one may be gone: restore again from a backup you know is good.",", and the database is started again. A failure before the load — staging the file, or stopping ",[17,1182,665],{}," — changes nothing.",[33,1185],{},[36,1187,1189],{"id":1188},"tls-at-the-front-door","TLS at the front door",[14,1191,1192,1193,1196],{},"The front door terminates TLS for the ",[403,1194,1195],{},"whole deployment"," — the platform, the console, and the API all sit behind that one endpoint. By default it serves plain HTTP, which suits a loopback deployment on a machine you trust. Anything else should be encrypted.",[14,1198,1199],{},"Behind the front door, traffic stays plain HTTP on the deployment's isolated internal network. Only the edge is encrypted.",[482,1201,1203],{"id":1202},"check-what-is-installed","Check what is installed",[41,1205,1207],{"className":43,"code":1206,"language":45,"meta":46,"style":46},".\u002Fbyodt tls status\n",[17,1208,1209],{"__ignoreMap":46},[50,1210,1211],{"class":52,"line":53},[50,1212,1206],{},[14,1214,1215],{},"With no certificate:",[41,1217,1220],{"className":1218,"code":1219,"language":412},[410],"==> No certificate — the front door serves plain HTTP.\n==> Add one with .\u002Fbyodt tls generate, or drop your own cert.pem + key.pem into tls\u002F, then .\u002Fbyodt restart proxy (.\u002Fbyodt up if the stack is not running).\n",[17,1221,1219],{"__ignoreMap":46},[14,1223,1224],{},"With one, it prints the certificate's subject, issuer, and validity dates.",[482,1226,1228],{"id":1227},"generate-a-self-signed-certificate","Generate a self-signed certificate",[41,1230,1232],{"className":43,"code":1231,"language":45,"meta":46,"style":46},".\u002Fbyodt tls generate                    # for this machine's hostname\n.\u002Fbyodt tls generate deployment.example # for a name you choose\n",[17,1233,1234,1239],{"__ignoreMap":46},[50,1235,1236],{"class":52,"line":53},[50,1237,1238],{},".\u002Fbyodt tls generate                    # for this machine's hostname\n",[50,1240,1241],{"class":52,"line":433},[50,1242,1243],{},".\u002Fbyodt tls generate deployment.example # for a name you choose\n",[14,1245,1246,1247,382,1250,1253,1254,1257,1258,1261,1262,1265],{},"This writes ",[17,1248,1249],{},"tls\u002Fcert.pem",[17,1251,1252],{},"tls\u002Fkey.pem"," — an RSA certificate valid for two years, carrying ",[17,1255,1256],{},"localhost",", the hostname you gave, and ",[17,1259,1260],{},"127.0.0.1"," as subject alternative names. ",[17,1263,1264],{},"openssl"," must be available on the host.",[14,1267,1268,1269,1271],{},"A self-signed certificate encrypts the connection and makes the browser treat the page as a secure context. It does ",[403,1270,959],{}," attest identity: browsers will warn, and you will have to accept it. That is expected and, for a deployment you run yourself, usually fine.",[482,1273,1275],{"id":1274},"use-your-own-certificate","Use your own certificate",[14,1277,1278,1279,382,1282,1285,1286,1289],{},"Put your ",[17,1280,1281],{},"cert.pem",[17,1283,1284],{},"key.pem"," into ",[17,1287,1288],{},"tls\u002F",". No naming choice — the front door looks for exactly those two filenames.",[482,1291,1293],{"id":1292},"apply-it","Apply it",[41,1295,1297],{"className":43,"code":1296,"language":45,"meta":46,"style":46},".\u002Fbyodt restart proxy\n",[17,1298,1299],{"__ignoreMap":46},[50,1300,1301],{"class":52,"line":53},[50,1302,1296],{},[14,1304,1305,1306,1308,1309,1312,1313,1316],{},"The front door re-reads the ",[17,1307,1288],{}," directory when its container is recreated, and switches to HTTPS if both files are present. The published port does not change: ",[17,1310,1311],{},"https:\u002F\u002F127.0.0.1:3000"," where it was ",[17,1314,1315],{},"http:\u002F\u002F"," before.",[452,1318,1319],{},[14,1320,1321,1323,1324,1326,1327,1329,1330,1333],{},[17,1322,256],{}," and the messages from ",[17,1325,112],{}," always print an ",[17,1328,1315],{}," address. With a certificate installed, browse to the same address over ",[17,1331,1332],{},"https:\u002F\u002F"," instead.",[482,1335,1337],{"id":1336},"go-back-to-plain-http","Go back to plain HTTP",[41,1339,1341],{"className":43,"code":1340,"language":45,"meta":46,"style":46},"rm tls\u002F*.pem\n.\u002Fbyodt restart proxy\n",[17,1342,1343,1348],{"__ignoreMap":46},[50,1344,1345],{"class":52,"line":53},[50,1346,1347],{},"rm tls\u002F*.pem\n",[50,1349,1350],{"class":52,"line":433},[50,1351,1296],{},[482,1353,1355],{"id":1354},"a-secure-context-is-required-for-cloud-sign-in","A secure context is required for cloud sign-in",[14,1357,1358,1359,1361,1362,105],{},"Browsers only expose the cryptography the cloud sign-in flow needs on a secure context — HTTPS, or a ",[17,1360,1256],{}," address. If you reach the deployment by any other address and try to sign in, the console tells you so and names this step. See ",[99,1363,1365],{"href":1364},"\u002Fbyodt-cloud\u002Fcloud","Cloud",[33,1367],{},[36,1369,187],{"id":1370},"upgrading-to-a-new-release",[14,1372,1373,1374,1376,1377,1380,1381,1383],{},"A release moves as one unit: the platform image, the console image, and the module payloads all follow ",[17,1375,791],{},". The graph database image is the exception: an upgrade leaves ",[17,1378,1379],{},"DB_IMAGE",", or ",[17,1382,776],{}," on Neo4j, where it is, unless you choose to move the database.",[14,1385,1386,1389,1390,1392,1393,1397,1398,1401,1402,1404,1405,382,1409,1413,1414,105],{},[17,1387,1388],{},".\u002Fbyodt upgrade"," does the whole upgrade: it downloads and checks the new release, backs up, moves the new files in, brings ",[17,1391,96],{}," into line, applies the release, and waits until it is healthy. The new release's ",[99,1394,1396],{"href":1395},"\u002Fbyodt-cloud\u002Finstallation#install-with-the-installer","installer"," does the same with ",[17,1399,1400],{},"--upgrade",". A deployment on 0.12.x or 0.13.0 has no ",[17,1403,1388],{}," yet; see ",[99,1406,1408],{"href":1407},"#upgrading-from-0130","Upgrading from 0.13.0",[99,1410,1412],{"href":1411},"#upgrading-from-012x","Upgrading from 0.12.x",". To do it all yourself instead, see ",[99,1415,1417],{"href":1416},"#upgrading-by-hand","Upgrading by hand",[482,1419,1421,1422],{"id":1420},"upgrade-with-byodt-upgrade","Upgrade with ",[17,1423,1388],{},[14,1425,1426],{},"From the deployment's folder:",[41,1428,1430],{"className":43,"code":1429,"language":45,"meta":46,"style":46},".\u002Fbyodt upgrade            # to the latest release\n.\u002Fbyodt upgrade X.Y.Z      # to a given release\n",[17,1431,1432,1437],{"__ignoreMap":46},[50,1433,1434],{"class":52,"line":53},[50,1435,1436],{},".\u002Fbyodt upgrade            # to the latest release\n",[50,1438,1439],{"class":52,"line":433},[50,1440,1441],{},".\u002Fbyodt upgrade X.Y.Z      # to a given release\n",[14,1443,1444,1445,1448],{},"Or run the new release's installer, which finds the deployment, or takes it from ",[17,1446,1447],{},"--dir",":",[41,1450,1452],{"className":43,"code":1451,"language":45,"meta":46,"style":46},"VERSION=X.Y.Z\ncurl --proto '=https' --tlsv1.2 -fsSL \"https:\u002F\u002Fgithub.com\u002Fdether-net\u002Fdethernety-oss\u002Freleases\u002Fdownload\u002Fv${VERSION}\u002Fget-byodt.sh\" \\\n  | sh -s -- --upgrade --dir \u002Fpath\u002Fto\u002Fyour\u002Fdeployment\n",[17,1453,1454,1459,1464],{"__ignoreMap":46},[50,1455,1456],{"class":52,"line":53},[50,1457,1458],{},"VERSION=X.Y.Z\n",[50,1460,1461],{"class":52,"line":433},[50,1462,1463],{},"curl --proto '=https' --tlsv1.2 -fsSL \"https:\u002F\u002Fgithub.com\u002Fdether-net\u002Fdethernety-oss\u002Freleases\u002Fdownload\u002Fv${VERSION}\u002Fget-byodt.sh\" \\\n",[50,1465,1466],{"class":52,"line":602},[50,1467,1468],{},"  | sh -s -- --upgrade --dir \u002Fpath\u002Fto\u002Fyour\u002Fdeployment\n",[14,1470,1471,1472,1474,1475,1478,1479,1481,1482,1484,1485,1488,1489,1492],{},"Both end in the same place: the new release's own ",[17,1473,19],{}," does the work from the third step below on. The installer downloads through your shell's ",[17,1476,1477],{},"HTTPS_PROXY","; ",[17,1480,1388],{}," downloads through the proxy ",[17,1483,96],{}," names, with the login from ",[17,1486,1487],{},".env.secrets",". A TLS-inspecting proxy's CA must then be in the host's trust store: ",[17,1490,1491],{},"proxy-ca\u002F"," reaches only the containers.",[14,1494,1495],{},[403,1496,1497],{},"Before you start:",[526,1499,1500,1509,1515,1530],{},[529,1501,1502,1505,1506],{},[403,1503,1504],{},"The database must be running",", because the upgrade backs up the graph first. If it is not, the upgrade stops with ",[17,1507,1508],{},"The database is not running, so the graph cannot be backed up first. Start it ('.\u002Fbyodt up'), or add --skip-graph-backup. Nothing was changed.",[529,1510,1511,1514],{},[403,1512,1513],{},"At least 2048 MiB free"," in the deployment's folder, for the new images and the backups.",[529,1516,1517,1520,1521,1524,1525,1529],{},[403,1518,1519],{},"The network",", as for the first start: the release assets on ",[17,1522,1523],{},"github.com",", the new images, and new model weights if the release changed the model (see ",[99,1526,1528],{"href":1527},"\u002Fbyodt-cloud\u002Finstallation#network-access-for-the-first-start","Installation → Network access for the first start","). The container engine pulls with its own proxy setting.",[529,1531,1532,1535],{},[403,1533,1534],{},"Copy the previous backups off the machine."," The upgrade takes its own backup, on the same machine.",[482,1537,1539],{"id":1538},"what-an-upgrade-does","What an upgrade does",[14,1541,1542],{},"In this order. Nothing in the deployment changes before step 5.",[1121,1544,1545,1555,1572,1591,1605,1648,1657,1751,1760,1770],{},[529,1546,1547,1550,1551,1554],{},[403,1548,1549],{},"Finds the release."," It reads the version and the bundle's SHA-256 from that release's ",[17,1552,1553],{},"get-byodt.sh",", as data, never run. With no version, it takes the latest release, which is never a pre-release.",[529,1556,1557,1560,1561,1564,1565,1569,1570,105],{},[403,1558,1559],{},"Downloads and checks the bundle"," into a private staging folder inside the deployment, ",[17,1562,1563],{},".byodt-upgrade.XXXXXX",": over HTTPS only, at most 50 MiB, with the SHA-256 the release published, and with cosign, its signature (see ",[99,1566,1568],{"href":1567},"#signatures","Signatures","). Then it hands over to the new release's own ",[17,1571,19],{},[529,1573,1574,1577,1578,1581,1582,1584,1585,1587,1588,1590],{},[403,1575,1576],{},"Checks everything first",", with the new release's code: the files the old release shipped, against the record of them (a file you edited stops the upgrade unless you add ",[17,1579,1580],{},"--replace-edited",", if the new release ships it too; 0.12.x keeps no record, see ",[99,1583,1412],{"href":1411},", but every upgrade writes one, so the upgrades after it find your edits); the ",[17,1586,96],{}," changes; a ",[17,1589,795],{}," pin; that no other folder runs this deployment; the free disk; and that the database answers.",[529,1592,1593,1596,1597,1600,1601,1604],{},[403,1594,1595],{},"Asks every question at once."," It shows what it will do, then asks ",[17,1598,1599],{},"Upgrade from A to B? [y\u002FN]",", then about each change below, and shows the ",[99,1602,1603],{"href":306},"third-party notice"," if the new release changes what you confirmed, or if there is no record of a confirmation yet, as on every deployment coming from 0.12.x or 0.13.0. Nothing is asked after this.",[529,1606,1607,1285,1610,1613,1614,1643,1645,1647],{},[403,1608,1609],{},"Backs up",[17,1611,1612],{},"backups\u002Fupgrade-A-to-B-\u003Ctime>\u002F",", a folder only you can read:",[526,1615,1616,1622,1637],{},[529,1617,1618,1619,1621],{},"the graph, taken by the current release's own ",[17,1620,921],{},";",[529,1623,1624,1626,1627,1630,1631,1626,1634,1621],{},[17,1625,96],{},", as ",[17,1628,1629],{},"env.before-B",", and the release record ",[17,1632,1633],{},".byodt-release",[17,1635,1636],{},"byodt-release.before-B",[529,1638,1639,1640,105],{},"every file the old or the new release ships, as it is here, your edits included, as ",[17,1641,1642],{},"bundle-files-A.tar.gz",[561,1644],{},[17,1646,1487],{}," is not copied: the upgrade leaves it alone.",[529,1649,1650,1653,1654,1656],{},[403,1651,1652],{},"Moves the new files in",", by rename, keeping a journal so an interruption can be resumed or undone. ",[17,1655,19],{}," itself goes first. Files the new release no longer ships stay where they are, as they are, and are listed for you to remove.",[529,1658,1659,1665,1666,1669,1670,1717,1719,1720,337,1722,337,1725,337,1728,1730,1731,1734,1735,337,1738,337,1741,337,1743,1746,1747,1750],{},[403,1660,1661,1662,1664],{},"Brings ",[17,1663,96],{}," into line"," with the new ",[17,1667,1668],{},".env.example",", as you answered:",[526,1671,1672,1677,1683,1686,1693,1699],{},[529,1673,1674,1676],{},[17,1675,791],{}," is set to the new release;",[529,1678,1679,1680,1682],{},"a setting the new release adds is appended, with its comment, as ",[17,1681,1668],{}," ships it;",[529,1684,1685],{},"a default the new release changed is taken only where your value is still the old default;",[529,1687,1688,1689,1692],{},"a setting the new release no longer uses is commented out, with ",[17,1690,1691],{},"# no longer used since B"," after it;",[529,1694,1695,1696,1698],{},"a ",[17,1697,795],{}," pinned to the old release is retagged to the new one;",[529,1700,1701,1702,1380,1704,1706,1707,1380,1710,1713,1714,105],{},"the database image (",[17,1703,1379],{},[17,1705,776],{}," on Neo4j) changes only if you chose to move the database: ",[17,1708,1709],{},"--move-db",[17,1711,1712],{},"y"," to ",[17,1715,1716],{},"Also move the database to …?",[561,1718],{},"Except as above, it never changes ",[17,1721,795],{},[17,1723,1724],{},"DB_ENGINE",[17,1726,1727],{},"DB_DATA",[17,1729,1379],{},", any ",[17,1732,1733],{},"NEO4J_*"," setting, ",[17,1736,1737],{},"CONTAINER_ENGINE",[17,1739,1740],{},"FRONT_DOOR_*",[17,1742,1477],{},[17,1744,1745],{},"NO_PROXY"," or ",[17,1748,1749],{},"UPGRADE_REQUIRE_SIGNATURE",". It also writes the new release record and, if you confirmed it, the notice's record.",[529,1752,1753,1756,1757,1759],{},[403,1754,1755],{},"Applies the release"," with ",[17,1758,170],{},": it pulls the new images and recreates the deployment.",[529,1761,1762,1765,1766,1769],{},[403,1763,1764],{},"Waits until it is healthy",": the platform and the front door healthy, and the console running, for up to ",[17,1767,1768],{},"--health-timeout"," seconds (1200 by default), with a progress line every 30 seconds.",[529,1771,1772,1775,1776,105],{},[403,1773,1774],{},"Prints the result"," and the exact ",[99,1777,1779],{"href":1778},"#rolling-back-an-upgrade","rollback steps",[14,1781,1782],{},"A run, trimmed:",[41,1784,1787],{"className":1785,"code":1786,"language":412},[410],"==> Upgrading from A to B.\n==> SHA-256 matches release B.\n==> Signature verified: the release workflow of dether-net\u002Fdethernety-oss at vB signed it.\n==> Upgrade from A to B:\n==>   new files: …\nUpgrade from A to B? [y\u002FN] y\n==> Backing up the graph with release A's own byodt…\n==> Backup written: backups\u002Fupgrade-A-to-B-20261101T182842Z\u002Fbyodt-snapshot-A-20261101-182844.snapshot (15M)\n==> Backed up into backups\u002Fupgrade-A-to-B-20261101T182842Z.\n==> Release B's files are in place.\n==> Applying release B…\n==> Pulling the pinned images…\n    …your container engine's pull and start output…\n==> Updated.\n==> Waiting for release B to be healthy (up to 1200 seconds)…\n==>   platform: starting, front door: healthy, console: running\n==> Healthy.\n==> Upgraded from A to B. The backup is in backups\u002Fupgrade-A-to-B-20261101T182842Z.\n==> To roll back later (everything since the backup is lost):\n  …the rollback steps…\n",[17,1788,1786],{"__ignoreMap":46},[482,1790,1792],{"id":1791},"options","Options",[14,1794,1795,1798,1799,382,1802,1805,1806,642],{},[17,1796,1797],{},".\u002Fbyodt upgrade --help"," lists them. On the installer's command line they are passed on to the upgrade, except ",[17,1800,1801],{},"--allow-unsigned",[17,1803,1804],{},"--require-signature",", which the installer applies itself, to its own check of the bundle (see ",[99,1807,1809],{"href":1808},"\u002Fbyodt-cloud\u002Finstallation#options","Installation → Options",[57,1811,1814],{"className":1812,"tabIndex":61,"role":62,"ariaLabel":1813},[60],"Table: Options",[65,1815,1816,1825],{},[68,1817,1818],{},[71,1819,1820,1823],{},[74,1821,1822],{},"Option",[74,1824,79],{},[81,1826,1827,1841,1853,1862,1871,1886,1903,1913],{},[71,1828,1829,1833],{},[86,1830,1831],{},[17,1832,389],{},[86,1834,1835,1836,1838,1839,105],{},"Ask nothing: confirm the upgrade, accept every ",[17,1837,96],{}," change, and count the third-party notice as confirmed. It never moves the database, and never implies ",[17,1840,1801],{},[71,1842,1843,1847],{},[86,1844,1845],{},[17,1846,1709],{},[86,1848,1849,1850,105],{},"Also move the database to the image the new release was tested with. One-way, and only after the graph backup: the upgrade refuses it with ",[17,1851,1852],{},"--skip-graph-backup",[71,1854,1855,1859],{},[86,1856,1857],{},[17,1858,1580],{},[86,1860,1861],{},"Go ahead although files the release shipped were edited here. They are replaced, and kept in the backup.",[71,1863,1864,1868],{},[86,1865,1866],{},[17,1867,1852],{},[86,1869,1870],{},"For when the database is not running: go on without backing up the graph. The rest of the backup is still taken, and the database is not moved.",[71,1872,1873,1877],{},[86,1874,1875],{},[17,1876,1804],{},[86,1878,1879,1880,777,1883,1885],{},"Refuse unless cosign verifies the new release. ",[17,1881,1882],{},"UPGRADE_REQUIRE_SIGNATURE=true",[17,1884,96],{}," does the same for every upgrade.",[71,1887,1888,1892],{},[86,1889,1890],{},[17,1891,1801],{},[86,1893,1894,1895,1897,1898,1900,1901,105],{},"Go ahead without a signature check when cosign is not installed, without asking about the signature. The SHA-256 is still checked, but it comes from the same release, so it shows the download is intact, not who made it. A signature cosign rejects always stops the upgrade. Refused when ",[17,1896,96],{}," sets ",[17,1899,1882],{},", and contradicts ",[17,1902,1804],{},[71,1904,1905,1910],{},[86,1906,1907],{},[17,1908,1909],{},"--health-timeout SECS",[86,1911,1912],{},"How long to wait for the new release to be healthy. Default 1200.",[71,1914,1915,1920],{},[86,1916,1917],{},[17,1918,1919],{},"--abandon",[86,1921,1922,1923,105],{},"Drop an interrupted upgrade: undo a half-done move, or print the rollback steps. See ",[99,1924,1926],{"href":1925},"#if-an-upgrade-stops","If an upgrade stops",[14,1928,1929,1935],{},[403,1930,1931,1932],{},"Local changes belong in ",[17,1933,1934],{},"compose.override.yaml",", which no release ships, so an upgrade never touches it. A shipped file you edited stops the upgrade before it changes anything, when the new release ships it too:",[41,1937,1940],{"className":1938,"code":1939,"language":412},[410],"error: These files here are not release A's as shipped: compose.yaml. An upgrade replaces them. Local changes belong in compose.override.yaml, which no bundle ships; move them there, or add --replace-edited (they are kept in the backup). Nothing was changed.\n",[17,1941,1939],{"__ignoreMap":46},[14,1943,1944,1947,1948,1951,1952,1954,1955,1957],{},[403,1945,1946],{},"Moving the database."," When the new release was tested with another database image than yours, the summary says so, and at a terminal the upgrade asks ",[17,1949,1950],{},"Also move the database to …? This cannot be undone; the backup comes first. [y\u002FN]",". ",[17,1953,1709],{}," answers yes; ",[17,1956,389],{}," alone answers no. A newer database writes data an older one cannot open, which is why the rollback steps then move the data aside.",[482,1959,1568],{"id":1960},"signatures",[14,1962,1963],{},"The SHA-256 is always checked. What happens next depends on cosign:",[57,1965,1968],{"className":1966,"tabIndex":61,"role":62,"ariaLabel":1967},[60],"Table: Signatures",[65,1969,1970,1980],{},[68,1971,1972],{},[71,1973,1974,1977],{},[74,1975,1976],{},"Situation",[74,1978,1979],{},"What the upgrade does",[81,1981,1982,1993,2004,2022,2040],{},[71,1983,1984,1987],{},[86,1985,1986],{},"cosign installed, and it verifies the bundle against the release's exact identity",[86,1988,1989,1990],{},"Goes on: ",[17,1991,1992],{},"Signature verified: the release workflow of dether-net\u002Fdethernety-oss at vB signed it.",[71,1994,1995,1998],{},[86,1996,1997],{},"cosign installed, and it does not verify",[86,1999,2000,2001],{},"Stops, with cosign's output: ",[17,2002,2003],{},"cosign could not verify the new bundle's signature against release B's identity (above). Nothing was changed.",[71,2005,2006,2009],{},[86,2007,2008],{},"No cosign, at a terminal",[86,2010,2011,2012,2015,2016,2018,2019,105],{},"Warns that the bundle's authenticity was not checked, and asks ",[17,2013,2014],{},"Use it anyway? [y\u002FN]",", unless you pass ",[17,2017,1801],{},". The installer asks ",[17,2020,2021],{},"The bundle's signature was not verified. Upgrade with it anyway? [y\u002FN]",[71,2023,2024,2030],{},[86,2025,2026,2027,2029],{},"No cosign, unattended (",[17,2028,389],{},", or no terminal)",[86,2031,2032,2033,2035,2036,2039],{},"Refuses, unless you pass ",[17,2034,1801],{},". The installer says ",[17,2037,2038],{},"cosign did not verify the bundle, and an unattended upgrade does not run code it cannot verify.",", then the same two ways forward.",[71,2041,2042,2045],{},[86,2043,2044],{},"No cosign, and a signature is required",[86,2046,2047],{},"Refuses, whatever else you pass.",[14,2049,2050],{},"The unattended refusal names both ways forward:",[41,2052,2055],{"className":2053,"code":2054,"language":412},[410],"error: cosign is not installed, so the bundle's signature was not checked, and an unattended upgrade does not run code it cannot verify. Install cosign (https:\u002F\u002Fgithub.com\u002Fsigstore\u002Fcosign), or pass --allow-unsigned knowingly. Nothing was changed.\n",[17,2056,2054],{"__ignoreMap":46},[14,2058,2059,2060,2062,2063,2065,2066,2068,2069,2071],{},"Install cosign, or pass ",[17,2061,1801],{}," once you have decided that the SHA-256 alone is enough. It comes from the same release as the bundle, so it shows the download is intact, not who made it. At a terminal, ",[17,2064,1801],{}," also skips the question. ",[17,2067,389],{}," never implies ",[17,2070,1801],{},": an unattended upgrade runs code it cannot verify only when you said so. No flag makes an upgrade use a bundle whose signature cosign rejects.",[14,2073,2074,459,2077,1380,2079,2081,2082,637,2084,2088,2089,1734,2091,2093,2094,2096,2097,382,2099,2101,2102,1746,2105,2108,2109,2112,2113,2115,2116,2118,2119],{},[403,2075,2076],{},"Requiring a signature.",[17,2078,1804],{},[17,2080,1882],{}," in the deployment's ",[17,2083,96],{},[99,2085,2087],{"href":2086},"\u002Fbyodt-cloud\u002Fconfiguration#upgrades","Configuration → Upgrades","), refuses any bundle cosign did not verify, including when cosign is not installed. With the ",[17,2090,96],{},[17,2092,1801],{}," is refused before anything is downloaded. ",[17,2095,1388],{}," refuses ",[17,2098,1804],{},[17,2100,1801],{}," together. A value other than ",[17,2103,2104],{},"true",[17,2106,2107],{},"false"," stops the upgrade before anything is downloaded too: ",[17,2110,2111],{},".env sets UPGRADE_REQUIRE_SIGNATURE=yes, which is neither true nor false. Nothing was changed."," Because ",[17,2114,96],{}," may hold it, an upgrade run by an account that cannot read ",[17,2117,96],{}," stops: ",[17,2120,2121],{},"byodt cannot read .env, which may require a signature (UPGRADE_REQUIRE_SIGNATURE). Run the upgrade as the account that owns it. Nothing was changed.",[14,2123,2124,2133,2134,2136,2137,2139],{},[403,2125,2126,2129,2130,105],{},[17,2127,2128],{},"curl",", else ",[17,2131,2132],{},"wget"," The upgrade downloads with ",[17,2135,2128],{}," when it is installed. ",[17,2138,2132],{}," cannot hold a download to HTTPS, so a download through it counts as transport that is not guaranteed HTTPS; without cosign, the refusal says so. The SHA-256 and the signature rule apply the same way.",[482,2141,2143],{"id":2142},"without-a-terminal","Without a terminal",[14,2145,2146,2147,2149,2150,2152,2153,2155],{},"An upgrade asks before it changes anything. From a script, add ",[17,2148,389],{},", and name the version: ",[17,2151,1388],{}," with no version moves to the latest release, which it does unattended only with ",[17,2154,389],{}," too.",[41,2157,2159],{"className":43,"code":2158,"language":45,"meta":46,"style":46},".\u002Fbyodt upgrade X.Y.Z --yes\n",[17,2160,2161],{"__ignoreMap":46},[50,2162,2163],{"class":52,"line":53},[50,2164,2158],{},[14,2166,2167,2168,2170,2171],{},"Without ",[17,2169,389],{}," and without a terminal, it stops: ",[17,2172,2173],{},"An upgrade asks before it changes anything. Without a terminal, add --yes. Nothing was changed.",[482,2175,1926],{"id":2176},"if-an-upgrade-stops",[14,2178,2179],{},"An interrupted upgrade (a lost connection, a closed terminal, a failed pull, a reboot) is resumed by running the same command again:",[41,2181,2183],{"className":43,"code":2182,"language":45,"meta":46,"style":46},".\u002Fbyodt upgrade\n",[17,2184,2185],{"__ignoreMap":46},[50,2186,2187],{"class":52,"line":53},[50,2188,2182],{},[14,2190,2191,2192,2195],{},"It reads where it stopped from its journal, ",[17,2193,2194],{},".byodt-upgrade.state",", and goes on from there:",[57,2197,2200],{"className":2198,"tabIndex":61,"role":62,"ariaLabel":2199},[60],"Table: If an upgrade stops",[65,2201,2202,2214],{},[68,2203,2204],{},[71,2205,2206,2209],{},[74,2207,2208],{},"Where it stopped",[74,2210,918,2211,2213],{},[17,2212,1388],{}," does",[81,2215,2216,2232,2251],{},[71,2217,2218,2221],{},[86,2219,2220],{},"Before the files moved (nothing changed but a backup)",[86,2222,2223,2224,1746,2226,2228,2229,2231],{},"Starts over, to the same release, with the options the interrupted run was given (such as ",[17,2225,1709],{},[17,2227,1768],{},"), then any you give now. A ",[17,2230,1768],{}," given now wins.",[71,2233,2234,2237],{},[86,2235,2236],{},"While the new files were moving in",[86,2238,2239,2240,2243,2244,2246,2247,2250],{},"Asks ",[17,2241,2242],{},"The new files were being moved in. Finish moving them in (y), or put the old ones back (n)? [Y\u002Fn]",". Without a terminal, ",[17,2245,389],{}," finishes the move, and ",[17,2248,2249],{},".\u002Fbyodt upgrade --abandon"," puts the old files back.",[71,2252,2253,2256],{},[86,2254,2255],{},"After the files moved",[86,2257,2258,2259,2261],{},"Finishes: ",[17,2260,96],{},", the apply, and the health check.",[14,2263,2264,2265,337,2267,382,2269,2271,2272,1448],{},"While the new files are in place but not yet applied, ",[17,2266,112],{},[17,2268,363],{},[17,2270,378],{}," refuse, so that nothing starts the new files with the old ",[17,2273,96],{},[41,2275,2278],{"className":2276,"code":2277,"language":412},[410],"error: An upgrade to B is half done (phase moved). Finish it with '.\u002Fbyodt upgrade', or undo it with '.\u002Fbyodt upgrade --abandon'.\n",[17,2279,2277],{"__ignoreMap":46},[14,2281,2282],{},"In the other phases they only warn that an upgrade is pending.",[14,2284,2285,2286,2288],{},"They also stop, in any phase, when ",[17,2287,2194],{}," is not a regular file owned by you (or root) with mode 600, since it names folders an upgrade moves and removes:",[41,2290,2293],{"className":2291,"code":2292,"language":412},[410],"error: .byodt-upgrade.state is not this deployment's own (a link, another account's, or readable by others); byodt does not act on it. Check it, and remove it to drop the upgrade.\n",[17,2294,2292],{"__ignoreMap":46},[14,2296,2297,2300],{},[403,2298,2299],{},"When the apply or the health check fails",", the upgrade stops and prints the rollback steps:",[526,2302,2303,2309],{},[529,2304,2305,2308],{},[17,2306,2307],{},"Applying B failed (above). If the pull failed, the old containers are still running. Fix what it names and run '.\u002Fbyodt upgrade' to go on, or roll back:"," and the steps. A failed pull leaves the running deployment as it was.",[529,2310,2311,2314,2315,2317],{},[17,2312,2313],{},"Release B did not report healthy within 1200 seconds. Still starting? '.\u002Fbyodt upgrade' checks again. To go back instead (everything since the backup is lost):"," and the steps. A first start that re-ingests data or downloads the model can take longer than the timeout; run ",[17,2316,1388],{}," again to wait some more.",[14,2319,2320,1756,2323,1448],{},[403,2321,2322],{},"Dropping an upgrade",[17,2324,2249],{},[57,2326,2328],{"className":2327,"tabIndex":61,"role":62,"ariaLabel":2199},[60],[65,2329,2330,2340],{},[68,2331,2332],{},[71,2333,2334,2336],{},[74,2335,2208],{},[74,2337,918,2338,2213],{},[17,2339,1919],{},[81,2341,2342,2350,2358],{},[71,2343,2344,2347],{},[86,2345,2346],{},"Before the files moved",[86,2348,2349],{},"Removes the staging folder and the journal. The backup stays.",[71,2351,2352,2355],{},[86,2353,2354],{},"While the files were moving in",[86,2356,2357],{},"Puts the old files back, then drops the upgrade.",[71,2359,2360,2362],{},[86,2361,2255],{},[86,2363,2364,2365,2368,2369,2371],{},"Prints the rollback steps, and asks ",[17,2366,2367],{},"Drop the upgrade's state now (you run the steps above)? [y\u002FN]",". Dropping it undoes nothing: the steps do. With ",[17,2370,389],{},", it drops it without asking.",[14,2373,2374,2375,2378,2379,2382],{},"Only one upgrade runs at a time: a second one stops with ",[17,2376,2377],{},"Another upgrade is running here (.byodt-upgrade.lock, process …). Wait for it. If none is running, remove .byodt-upgrade.lock (and .byodt-upgrade.lock.takeover, if it is there) and run the command again."," A lock whose process has ended is taken over, under a second lock, ",[17,2380,2381],{},".byodt-upgrade.lock.takeover",", so that only one upgrade takes it over. A lock that names no process yet counts as held.",[482,2384,2386],{"id":2385},"rolling-back-an-upgrade","Rolling back an upgrade",[14,2388,2389,2390],{},"An upgrade prints the exact steps that take the deployment back to the release before it, from its backup, at the end and whenever it stops after the files moved. Keep them, and keep the backup folder. ",[403,2391,2392],{},"Everything created since the backup is lost.",[41,2394,2397],{"className":2395,"code":2396,"language":412},[410],"==> To roll back later (everything since the backup is lost):\n  cd '\u002Fpath\u002Fto\u002Fyour\u002Fdeployment'\n  .\u002Fbyodt down\n  rm -f \u003Ca file B added>\n  tar -xzf backups\u002Fupgrade-A-to-B-20261101T182842Z\u002Fbundle-files-A.tar.gz --strip-components=1\n  cp -p backups\u002Fupgrade-A-to-B-20261101T182842Z\u002Fenv.before-B .env\n  cp -p backups\u002Fupgrade-A-to-B-20261101T182842Z\u002Fbyodt-release.before-B .byodt-release\n  .\u002Fbyodt update\n  .\u002Fbyodt restore backups\u002Fupgrade-A-to-B-20261101T182842Z\u002Fbyodt-snapshot-A-20261101-182844.snapshot\n  .\u002Fbyodt restart platform\n",[17,2398,2396],{"__ignoreMap":46},[526,2400,2401,2414,2424,2434,2448,2459],{},[529,2402,2403,2409,2410,2413],{},[403,2404,2405,2406],{},"They start with a ",[17,2407,2408],{},"cd"," into the deployment's folder; run them in order, from there. When the upgrade stopped partway, ",[17,2411,2412],{},".\u002Fbyodt upgrade --abandon --yes"," comes next: it drops the upgrade's journal before the files go back.",[529,2415,2416,2423],{},[403,2417,2418,2419,2422],{},"The ",[17,2420,2421],{},"rm -f"," lines"," remove the files the new release added, one line each, so that the unpack brings back exactly what was there before, your own files included.",[529,2425,2426,2429,2430,2433],{},[403,2427,2428],{},"The release record"," is put back from the backup, or removed (",[17,2431,2432],{},"rm -f .byodt-release",") when the old release had none.",[529,2435,2436,2441,2442,337,2444,2447],{},[403,2437,2438,2439],{},"After ",[17,2440,1709],{}," a line moves the newer database's data aside (with the default ",[17,2443,1727],{},[17,2445,2446],{},"mv .\u002Fdata\u002Fmemgraph .\u002Fdata\u002Fmemgraph.moved-B","), or removes its named volume, because the older database cannot open it.",[529,2449,2450,2458],{},[403,2451,2452,2455,2456],{},[17,2453,2454],{},".\u002Fbyodt restore"," asks you to type ",[17,2457,512],{}," before it replaces the graph.",[529,2460,2461,2465,2466,2469],{},[403,2462,2438,2463],{},[17,2464,1852],{}," the restore line reads ",[17,2467,2468],{},"(no graph backup was taken)",": restore a backup of your own, if you took one.",[482,2471,2473],{"id":2472},"same-version-and-downgrades","Same version and downgrades",[14,2475,2476],{},"An upgrade only moves forward:",[526,2478,2479,2495],{},[529,2480,2481,459,2484,2487,2488,2491,2492],{},[403,2482,2483],{},"The same release:",[17,2485,2486],{},"Already on A. '.\u002Fbyodt update' applies it again."," The installer says ",[17,2489,2490],{},"The deployment in … already runs release A; '…\u002Fbyodt update' applies it again.",", or, for a folder that was set up but never started, ",[17,2493,2494],{},"The deployment in … already holds release A, and has not been started yet; '…\u002Fbyodt up' starts it.",[529,2496,2497,459,2500],{},[403,2498,2499],{},"An older release:",[17,2501,2502],{},"B is older than A: a downgrade is a rollback, not an upgrade. Roll back with the steps the upgrade to A printed, from its backup.",[14,2504,2505],{},"Nothing is changed either way.",[482,2507,1408],{"id":2508},"upgrading-from-0130",[14,2510,2511,2512,2514,2515,2517,2518,2520],{},"Release 0.13.0's ",[17,2513,19],{}," has no upgrade: its ",[17,2516,1388],{}," is another name for ",[17,2519,363],{},". It ignores the version, pulls 0.13.0's images again, and stays on 0.13.0:",[41,2522,2525],{"className":2523,"code":2524,"language":412},[410],"$ .\u002Fbyodt upgrade X.Y.Z\n==> Pulling the pinned images…\n    …\n==> Applying…\n    …\n==> Updated.\n",[17,2526,2524],{"__ignoreMap":46},[14,2528,2529,2530,2532],{},"To upgrade a 0.13.0 deployment, run the new release's installer with ",[17,2531,1400],{},", naming the deployment's folder:",[41,2534,2536],{"className":43,"code":2535,"language":45,"meta":46,"style":46},"VERSION=X.Y.Z\ncurl --proto '=https' --tlsv1.2 -fsSL \"https:\u002F\u002Fgithub.com\u002Fdether-net\u002Fdethernety-oss\u002Freleases\u002Fdownload\u002Fv${VERSION}\u002Fget-byodt.sh\" \\\n  | sh -s -- --upgrade --dir \u002Fpath\u002Fto\u002Fbyodt-0.13.0\n",[17,2537,2538,2542,2546],{"__ignoreMap":46},[50,2539,2540],{"class":52,"line":53},[50,2541,1458],{},[50,2543,2544],{"class":52,"line":433},[50,2545,1463],{},[50,2547,2548],{"class":52,"line":602},[50,2549,2550],{},"  | sh -s -- --upgrade --dir \u002Fpath\u002Fto\u002Fbyodt-0.13.0\n",[14,2552,2553,2554,2556,2557,2561,2562,2564,2565,2567,2568,2570,2571,2573],{},"The new release's ",[17,2555,19],{}," then does everything ",[99,2558,2560],{"href":2559},"#what-an-upgrade-does","described above",". It knows the files 0.13.0 shipped, so your edits are found as on any other release. The graph backup is taken by 0.13.0's own ",[17,2563,19],{},", and the rollback steps bring back 0.13.0's, whose ",[17,2566,512],{}," also asks you to type ",[17,2569,512],{},". From then on, ",[17,2572,1388],{}," does the next upgrade.",[14,2575,2576,2579,2580,2582,2583,2585,2586,2589,2590,2592,2593,2595],{},[403,2577,2578],{},"If it stops"," before the first file moved in, the deployment still has 0.13.0's ",[17,2581,19],{},", whose ",[17,2584,359],{}," cannot resume it. Run the installer again: it takes the upgrade over, and says ",[17,2587,2588],{},"An earlier upgrade stopped before it changed anything; starting this one in its place."," If it stopped later, the new ",[17,2591,19],{}," is already in place: run ",[17,2594,1388],{}," to go on.",[482,2597,1412],{"id":2598},"upgrading-from-012x",[14,2600,2601,2602,2604,2605,2517,2607,2609],{},"A 0.12.x deployment upgrades the same way as one on 0.13.0: once, with a release's installer and ",[17,2603,1400],{},", naming the deployment's folder. Release 0.12.x's ",[17,2606,1388],{},[17,2608,363],{}," too. You do not need to step through 0.13.0 or 0.14.0 first.",[41,2611,2612],{"className":43,"code":1451,"language":45,"meta":46,"style":46},[17,2613,2614,2618,2622],{"__ignoreMap":46},[50,2615,2616],{"class":52,"line":53},[50,2617,1458],{},[50,2619,2620],{"class":52,"line":433},[50,2621,1463],{},[50,2623,2624],{"class":52,"line":602},[50,2625,1468],{},[14,2627,2628,2631,2632,2634,2635,2638,2639,2642],{},[403,2629,2630],{},"Use the installer of a release later than 0.14.0, not 0.14.0's."," A 0.12.x folder keeps the ",[17,2633,665],{}," service in ",[17,2636,2637],{},"compose.yaml"," and has no ",[17,2640,2641],{},"compose.memgraph.yaml",". 0.14.0's installer cannot read that layout before its files move in, so it stops at the database check, although the database is running:",[41,2644,2647],{"className":2645,"code":2646,"language":412},[410],"error: The database is not running, so the graph cannot be backed up first. Start it ('\u002Fpath\u002Fto\u002Fyour\u002Fdeployment\u002Fbyodt up'), or add --skip-graph-backup. Nothing was changed.\n",[17,2648,2646],{"__ignoreMap":46},[14,2650,2651,2652,2654,2655,2657],{},"With a ",[17,2653,1934],{}," it also warns, wrongly, that it could not read that file. Nothing is changed. Do not add ",[17,2656,1852],{}," to get past it: run the installer of a release later than 0.14.0 instead.",[14,2659,2660,2663,2664,2666],{},[403,2661,2662],{},"One thing differs: edit detection."," 0.12.x keeps no record of the files it shipped, so the new ",[17,2665,19],{}," cannot tell whether you edited them. It says so, naming your release, and goes on. On 0.12.1:",[41,2668,2671],{"className":2669,"code":2670,"language":412},[410],"warning: byodt cannot tell whether release 0.12.1's files were edited here (no record of them); any edits are kept in the backup.\n",[17,2672,2670],{"__ignoreMap":46},[14,2674,2675,2676,2678,2679,2681,2682,2685,2686,2689,2690,2692],{},"It then replaces an edited shipped file, such as ",[17,2677,2637],{},", without asking and without ",[17,2680,1580],{},". The old file is kept in the upgrade's backup folder, in ",[17,2683,2684],{},"bundle-files-\u003Crelease>.tar.gz"," (",[17,2687,2688],{},"bundle-files-0.12.1.tar.gz"," on 0.12.1). Before you upgrade, move local changes into ",[17,2691,1934],{},", which no release ships. The upgrade writes the record of the new release's files, so the next upgrade finds your edits again.",[14,2694,2695,2696,1448],{},"Everything else is as ",[99,2697,2698],{"href":1407},"from 0.13.0",[526,2700,2701,2714,2725,2754,2782],{},[529,2702,2703,2706,2707,2709,2710,2567,2712,105],{},[403,2704,2705],{},"The graph backup"," is taken by 0.12.x's own ",[17,2708,19],{},", and the rollback steps bring back 0.12.x's, whose ",[17,2711,512],{},[17,2713,512],{},[529,2715,2716,2718,2719,2721,2722,2724],{},[403,2717,2578],{},", run the installer again, or ",[17,2720,1388],{}," once the new ",[17,2723,19],{}," is in place, as from 0.13.0.",[529,2726,2727,2730,2731,773,2733,777,2736,2738,2739,2741,2742,2744,2745,2747,2748,2751,2752,105],{},[403,2728,2729],{},"The changes 0.13.0 made are done for you."," The new ",[17,2732,19],{},[17,2734,2735],{},"DB_ENGINE=memgraph",[17,2737,96],{}," on its first run, and the ",[17,2740,665],{}," service moves into ",[17,2743,2641],{},", so run the stack through ",[17,2746,19],{}," only. It warns about an override file with another name, such as ",[17,2749,2750],{},"compose.override.yml","; rename it to ",[17,2753,1934],{},[529,2755,2756,2769,2770,2773,2774,2777,2778,2781],{},[403,2757,2758,2759,2763,2764,105],{},"Read the ",[2760,2761,2762],"em",{},"Upgrading"," notes of 0.13.0 and of every later release in the ",[99,2765,2768],{"href":2766,"rel":2767},"https:\u002F\u002Fgithub.com\u002Fdether-net\u002Fdethernety-oss\u002Fblob\u002Fmain\u002FCHANGELOG.md",[852],"CHANGELOG"," An upgrade from 0.12.x skips past them all, and nothing checks the steps they ask of you. 0.13.0's, for example: update each installed module that has a frontend to a version that ships ",[17,2771,2772],{},"frontend\u002Ffrontend-manifest.json","; reload any browser tab left open across the upgrade; a CDN or reverse proxy in front of dt-ws must honour ",[17,2775,2776],{},"Cache-Control: private"," on ",[17,2779,2780],{},"\u002Fmodule-bundles\u002F",", and must not cache it by path.",[529,2783,2784,2789,2790,2792,2793,105],{},[403,2785,2786,2787],{},"On Memgraph with ",[17,2788,1051],{},", 0.12.x's graph backup fails as 0.13.0's does. Take the snapshot by hand and add ",[17,2791,1852],{},"; see ",[99,2794,2796],{"href":2795},"#upgrading-on-podman","Upgrading on Podman",[482,2798,2796],{"id":2799},"upgrading-on-podman",[14,2801,2786,2802,2804,2805,2807,2808,2810,2811,105],{},[17,2803,1051],{},", this release backs up and restores the graph through ",[17,2806,1047],{},", so ",[17,2809,1388],{}," works as it does on Docker. On a host that also has Docker, set the Compose provider first; see ",[99,2812,2814],{"href":2813},"\u002Fbyodt-cloud\u002Finstallation#podman-specifics","Installation → Podman specifics",[14,2816,2817,2822,2823,2825,2826,2829,2830,2832,2833,2836],{},[403,2818,2819,2820],{},"From 0.12.x or 0.13.0, on Memgraph and ",[17,2821,1051],{},", the upgrade's graph backup is taken by the old release's ",[17,2824,19],{},", which copies with ",[17,2827,2828],{},"compose cp",", a command ",[17,2831,1051],{}," does not have. The upgrade stops there with ",[17,2834,2835],{},"Failed to copy the snapshot out of the db container.",", and nothing is changed. Take the snapshot by hand, then upgrade without the graph backup.",[1121,2838,2839,2886],{},[529,2840,2841,2842,1448,2845,2875,2877,2878,2881,2882,2885],{},"From the deployment's folder, with the deployment running, take a Memgraph snapshot and copy it out. In ",[17,2843,2844],{},"bash",[41,2846,2848],{"className":43,"code":2847,"language":45,"meta":46,"style":46},"id=\"$(podman ps -q --filter label=com.docker.compose.project=dethernety --filter label=com.docker.compose.service=db)\"\npodman exec -i \"$id\" sh -c 'FLAGS_password=\"$MEMGRAPH_PASSWORD\" mgconsole --username \"$MEMGRAPH_USER\" --fromenv=password' \u003C\u003C\u003C 'CREATE SNAPSHOT;'\nsnap=\"$(podman exec \"$id\" sh -c 'ls -t \u002Fvar\u002Flib\u002Fmemgraph\u002Fsnapshots | head -1')\"\nmkdir -p backups && podman cp \"$id:\u002Fvar\u002Flib\u002Fmemgraph\u002Fsnapshots\u002F$snap\" backups\u002Fbefore-upgrade.snapshot\nls -l backups\u002Fbefore-upgrade.snapshot\n",[17,2849,2850,2855,2860,2865,2870],{"__ignoreMap":46},[50,2851,2852],{"class":52,"line":53},[50,2853,2854],{},"id=\"$(podman ps -q --filter label=com.docker.compose.project=dethernety --filter label=com.docker.compose.service=db)\"\n",[50,2856,2857],{"class":52,"line":433},[50,2858,2859],{},"podman exec -i \"$id\" sh -c 'FLAGS_password=\"$MEMGRAPH_PASSWORD\" mgconsole --username \"$MEMGRAPH_USER\" --fromenv=password' \u003C\u003C\u003C 'CREATE SNAPSHOT;'\n",[50,2861,2862],{"class":52,"line":602},[50,2863,2864],{},"snap=\"$(podman exec \"$id\" sh -c 'ls -t \u002Fvar\u002Flib\u002Fmemgraph\u002Fsnapshots | head -1')\"\n",[50,2866,2867],{"class":52,"line":608},[50,2868,2869],{},"mkdir -p backups && podman cp \"$id:\u002Fvar\u002Flib\u002Fmemgraph\u002Fsnapshots\u002F$snap\" backups\u002Fbefore-upgrade.snapshot\n",[50,2871,2872],{"class":52,"line":614},[50,2873,2874],{},"ls -l backups\u002Fbefore-upgrade.snapshot\n",[561,2876],{},"The password stays inside the database container: ",[17,2879,2880],{},"mgconsole"," reads it from the container's own environment. The copy keeps the container file's mode; ",[17,2883,2884],{},"chmod 600 backups\u002Fbefore-upgrade.snapshot"," makes it readable by you only.",[529,2887,2888,2889,2907,2909,2910,2913],{},"Upgrade with the installer, without the graph backup:",[41,2890,2892],{"className":43,"code":2891,"language":45,"meta":46,"style":46},"VERSION=X.Y.Z\ncurl --proto '=https' --tlsv1.2 -fsSL \"https:\u002F\u002Fgithub.com\u002Fdether-net\u002Fdethernety-oss\u002Freleases\u002Fdownload\u002Fv${VERSION}\u002Fget-byodt.sh\" \\\n  | sh -s -- --upgrade --dir \u002Fpath\u002Fto\u002Fyour\u002Fdeployment --skip-graph-backup\n",[17,2893,2894,2898,2902],{"__ignoreMap":46},[50,2895,2896],{"class":52,"line":53},[50,2897,1458],{},[50,2899,2900],{"class":52,"line":433},[50,2901,1463],{},[50,2903,2904],{"class":52,"line":602},[50,2905,2906],{},"  | sh -s -- --upgrade --dir \u002Fpath\u002Fto\u002Fyour\u002Fdeployment --skip-graph-backup\n",[561,2908],{},"The summary says ",[17,2911,2912],{},"the graph is NOT backed up (--skip-graph-backup)",", and the rest of the backup is taken as usual.",[14,2915,2916,2917,2919,2920,2923,2924,2927,2928,2930,2931,2933,2934,105],{},"The rollback steps of such an upgrade read ",[17,2918,2468],{},": the graph to go back to is ",[17,2921,2922],{},"backups\u002Fbefore-upgrade.snapshot",". On the new release, ",[17,2925,2926],{},".\u002Fbyodt restore backups\u002Fbefore-upgrade.snapshot"," restores it. The old release's own Memgraph ",[17,2929,512],{}," copies with ",[17,2932,2828],{}," too, so after a rollback to 0.12.x or 0.13.0 it cannot load the snapshot on ",[17,2935,1051],{},[482,2937,1417],{"id":2938},"upgrading-by-hand",[14,2940,2167,2941,2943,2944,2946],{},[17,2942,1388],{},", these are the steps. ",[17,2945,1388],{}," does all of them, and checks each one first. Two things it does that a hand upgrade does not:",[526,2948,2949,2960],{},[529,2950,2951,459,2954,2956,2957,2959],{},[403,2952,2953],{},"The release record.",[17,2955,1633],{}," keeps naming the old release, so the next ",[17,2958,1388],{}," cannot tell which shipped files you edited. It warns, and keeps any edits in its backup.",[529,2961,2962,2965,2966,2968],{},[403,2963,2964],{},"The third-party notice."," When the new release changes what you confirmed, the next ",[17,2967,170],{}," shows the notice and asks before it pulls.",[2970,2971,2973],"h4",{"id":2972},"_1-back-up-first","1. Back up first",[41,2975,2977],{"className":43,"code":2976,"language":45,"meta":46,"style":46},".\u002Fbyodt backup\n",[17,2978,2979],{"__ignoreMap":46},[50,2980,2981],{"class":52,"line":53},[50,2982,2976],{},[14,2984,2985],{},"Copy the file off the machine. A backup may not load across versions, so treat it as protection against a failed upgrade, not a guaranteed rollback.",[2970,2987,2989],{"id":2988},"_2-get-the-new-bundle","2. Get the new bundle",[14,2991,2992,2993,2997,2998,3000],{},"Download and verify it exactly as in ",[99,2994,2996],{"href":2995},"\u002Fbyodt-cloud\u002Finstallation#get-the-bundle","Installation → Get the bundle",". Behind an outbound proxy, export ",[17,2999,1477],{}," in your shell first, as on the first install.",[452,3002,3006],{"className":3003},[3004,3005],"callout","callout-note",[14,3007,3008,3011,3012,3014,3015,3017,3018,3020],{},[403,3009,3010],{},"Note:"," An upgrade needs the network again: the new images' layers, the new release's module index and payloads, and new model weights if the release changed the model. The hosts are the ones in ",[99,3013,1528],{"href":1527},". Behind a proxy, the container engine pulls with its own proxy setting, as on the first install; on a host with no direct route out, ",[17,3016,170],{}," cannot pull without it. On Docker, ",[17,3019,170],{}," warns before it pulls when the daemon has no proxy. A failed pull leaves the running deployment as it was.",[2970,3022,3024],{"id":3023},"_3-replace-the-bundle-files-keep-your-own","3. Replace the bundle files, keep your own",[14,3026,3027],{},"The tarball contains only the shipped files — the control script, the compose files, the configuration template, the proxy configuration, and the notices. It contains none of your generated files, so unpacking it over your existing bundle directory replaces the former and leaves the latter alone:",[41,3029,3031],{"className":43,"code":3030,"language":45,"meta":46,"style":46},"VERSION=X.Y.Z    # the release you are moving to\ntar xzf \"byodt-${VERSION}.tar.gz\" --strip-components=1 -C \u002Fpath\u002Fto\u002Fyour\u002Fbundle\n",[17,3032,3033,3038],{"__ignoreMap":46},[50,3034,3035],{"class":52,"line":53},[50,3036,3037],{},"VERSION=X.Y.Z    # the release you are moving to\n",[50,3039,3040],{"class":52,"line":433},[50,3041,3042],{},"tar xzf \"byodt-${VERSION}.tar.gz\" --strip-components=1 -C \u002Fpath\u002Fto\u002Fyour\u002Fbundle\n",[14,3044,3045,3046,337,3048,337,3050,337,3053,337,3055,337,3057,337,3059,337,3061,382,3063,3066],{},"Your ",[17,3047,96],{},[17,3049,1487],{},[17,3051,3052],{},"mode\u002F",[17,3054,1288],{},[17,3056,1491],{},[17,3058,1072],{},[17,3060,214],{},[17,3062,1633],{},[17,3064,3065],{},"third-party-acknowledgement.log"," are untouched.",[2970,3068,3070,3071,3073,3074],{"id":3069},"_4-bring-env-into-line-with-the-new-envexample","4. Bring ",[17,3072,96],{}," into line with the new ",[17,3075,1668],{},[14,3077,3078,3080,3081,1448],{},[17,3079,1668],{}," is the release manifest. Compare it with your ",[17,3082,96],{},[41,3084,3086],{"className":43,"code":3085,"language":45,"meta":46,"style":46},"diff .env .env.example\n",[17,3087,3088],{"__ignoreMap":46},[50,3089,3090],{"class":52,"line":53},[50,3091,3085],{},[14,3093,3094,3100,3101,3104,3105,3107,3108,3110,3111,1746,3113,3115,3116,3118,3119,3115,3121,3123,3124,3126],{},[403,3095,3096,3097,3099],{},"Set ",[17,3098,791],{}," to the new version."," That is the whole version change — the platform image, the console image, and the module payloads all follow it. Also take any changes to ",[17,3102,3103],{},"PROXY_IMAGE",", and read the new file's comments for settings that were added or retired. ",[17,3106,170],{}," never changes your settings in ",[17,3109,96],{},": it only records a missing ",[17,3112,1737],{},[17,3114,1724],{}," (on Neo4j, ",[17,3117,776],{}," too). Keep your current ",[17,3120,1379],{},[17,3122,776],{},", which ",[17,3125,19],{}," recorded on the first run), even if the new bundle names a newer database, unless you decide to move the database (below).",[14,3128,3129,459,3132,3134,3135,382,3137,3139,3140,3142,3143,777,3146,3148,3149,3152,3153,3155,3156,3158],{},[403,3130,3131],{},"The outbound proxy keys.",[17,3133,1668],{}," has an \"Outbound proxy\" section with ",[17,3136,1477],{},[17,3138,1745],{},", both commented out; an ",[17,3141,96],{}," carried over from an older bundle has neither. They are optional, as are ",[17,3144,3145],{},"HTTPS_PROXY_USERINFO",[17,3147,1487],{}," and the CA file ",[17,3150,3151],{},"proxy-ca\u002Fproxy-ca.pem",": add them only if the host reaches the internet through a proxy (see ",[99,3154,641],{"href":640},"). An older bundle passed no proxy variables to its containers, so an engine that copies your shell's or your Docker client's proxy settings into containers could pass them on. A bundle with these keys sets every proxy variable of its containers explicitly, and uses only what ",[17,3157,96],{}," says.",[452,3160,3161],{},[14,3162,3163,3166,3167,382,3169,3171,3172,3174,3175,3177,3178,3180,3181,1746,3184,3187,3188,3174,3190,3192,3193,105],{},[403,3164,3165],{},"Moving the database to a newer image is your choice, and it is one-way."," A newer database writes data that an older one cannot open, so there is no downgrade. ",[17,3168,112],{},[17,3170,170],{}," warn when ",[17,3173,1379],{}," (or ",[17,3176,776],{},") differs from the image this bundle was tested with; the warning never blocks the start. To move: back up first — ",[17,3179,921],{},", or a copy of the data directory (",[17,3182,3183],{},"data\u002Fmemgraph",[17,3185,3186],{},"data\u002Fneo4j",") taken with the deployment down — then set ",[17,3189,1379],{},[17,3191,776],{},") to the tested image and run ",[17,3194,170],{},[452,3196,3197],{},[14,3198,3199,3205],{},[403,3200,3201,3202,3204],{},"If you have uncommented ",[17,3203,795],{}," to use a mirror",", move its tag to the new version too. The console refuses to serve a platform version it was not built for, so an override left on the old tag aborts the start. Leaving the key commented out — the default — makes this impossible.",[2970,3207,3209],{"id":3208},"_5-apply","5. Apply",[41,3211,3213],{"className":43,"code":3212,"language":45,"meta":46,"style":46},".\u002Fbyodt update\n",[17,3214,3215],{"__ignoreMap":46},[50,3216,3217],{"class":52,"line":53},[50,3218,3212],{},[14,3220,3221,3222,637,3224,3232],{},"This first checks ",[17,3223,96],{},[99,3225,3227,3228,3231],{"href":3226},"#upgrading-from-a-release-with-the-ollama-service","Upgrading from a release with the ",[17,3229,3230],{},"ollama"," service"," for what it refuses and what it only notes), then pulls the newly pinned images and recreates the deployment. The one-shot runs again and installs the new release's signed modules; the reference-data ingest is skipped if the corpus has not changed.",[14,3234,3235,3236,3238,3239,3242,3243,3245],{},"If the one-shot refuses the start, ",[17,3237,170],{}," fails with an error that ends ",[17,3240,3241],{},"'.\u002Fbyodt logs console-init' says why."," Read that log, fix what it names, and run ",[17,3244,170],{}," again.",[2970,3247,3249],{"id":3248},"_6-verify","6. Verify",[41,3251,3252],{"className":43,"code":653,"language":45,"meta":46,"style":46},[17,3253,3254],{"__ignoreMap":46},[50,3255,3256],{"class":52,"line":53},[50,3257,653],{},[14,3259,3260,3261,3264,3265,1746,3268,3271,3272,105],{},"Then open the console and confirm: a ",[403,3262,3263],{},"Healthy"," verdict, every module ",[17,3266,3267],{},"placed",[17,3269,3270],{},"skipped",", and the init tag under the page heading showing the new version. If anything is off, see ",[99,3273,3275],{"href":3274},"\u002Fbyodt-cloud\u002Ftroubleshooting","Troubleshooting",[482,3277,3227,3279,3231],{"id":3278},"upgrading-from-a-release-with-the-ollama-service",[17,3280,3230],{},[14,3282,3283,3284,3287,3288,3290,3291,3293,3294,3296],{},"From control script ",[403,3285,3286],{},"1.2.0"," on, the bundle no longer runs the old ",[17,3289,3230],{}," service: the platform embeds in process. Upgrading a deployment that ran the ",[17,3292,3230],{}," service follows the steps of ",[99,3295,1417],{"href":1416},", with these additions.",[1121,3298,3299,3320,3335,3379,3390,3404,3410],{},[529,3300,3301,3304,3305,3307,3308,3310,3311],{},[403,3302,3303],{},"Back up, and keep what a rollback needs",", as in step 1: ",[17,3306,921],{},", and copy the file off the machine. Also save your current ",[17,3309,96],{},", and keep the previous release's bundle tarball:",[41,3312,3314],{"className":43,"code":3313,"language":45,"meta":46,"style":46},"cp .env .env.before-\u003Cversion>    # \u003Cversion>: the release you are moving to\n",[17,3315,3316],{"__ignoreMap":46},[50,3317,3318],{"class":52,"line":53},[50,3319,3313],{},[529,3321,3322,3327,3328,3330,3331,3334],{},[403,3323,3324,3325],{},"Make room on disk, take the new bundle and set ",[17,3326,791],{},", as in steps 2 to 4. The new release needs free disk for the model's weights (about 1.26 GB in ",[17,3329,200],{},") plus the new images. Do not count on the space ",[17,3332,3333],{},"data\u002Follama"," takes: it can only go after the upgrade has worked (step 7).",[529,3336,3337,3343,3349,3351,337,3353,382,3355,459,3357,3360,3361,3363,3364,3367,3368,472,3371,3374,3375,3378],{},[403,3338,3339,3340,3342],{},"In ",[17,3341,96],{},", remove (or comment out) three lines:",[41,3344,3347],{"className":3345,"code":3346,"language":412},[410],"EMBEDDING_MODEL=embeddinggemma\nEMBEDDING_SIMILARITY_THRESHOLD=…\nOLLAMA_IMAGE=…\n",[17,3348,3346],{"__ignoreMap":46},[561,3350],{},[17,3352,112],{},[17,3354,170],{},[17,3356,194],{},[403,3358,3359],{},"refuse"," to run while ",[17,3362,867],{}," is set — however it is quoted, exported, or followed by a comment — and tell you to remove the line. Any ",[17,3365,3366],{},"OLLAMA_*"," line, ",[17,3369,3370],{},"EMBEDDING_URL",[17,3372,3373],{},"EMBEDDING_SIMILARITY_THRESHOLD"," only get a notice that they are no longer used. Leave ",[17,3376,3377],{},"EMBEDDING_MODEL"," unset: the platform's default is the model this release's reference data was embedded with.",[529,3380,3381,459,3384,637,3386,3389],{},[403,3382,3383],{},"Optionally, download the model ahead:",[17,3385,194],{},[99,3387,822],{"href":3388},"#the-embedding-model","). Otherwise the platform downloads it on its first start.",[529,3391,3392,459,3395,3397,3398,3400,3401,3403],{},[403,3393,3394],{},"Apply:",[17,3396,170],{},". It removes the old ",[17,3399,3230],{}," container for you (found by its compose labels; its image and ",[17,3402,3333],{}," are kept) and starts the new release.",[529,3405,3406,3409],{},[403,3407,3408],{},"Verify",", as in step 6.",[529,3411,3412,459,3415,337,3417,382,3419,3421,3422,3424,3425,3427,3428,3430,3431,3434,3435,3444,3446,3447,3449,3450,3452,3453,3456],{},[403,3413,3414],{},"Once the new start has worked, optionally reclaim the disk.",[17,3416,112],{},[17,3418,170],{},[17,3420,194],{}," report a leftover ",[17,3423,3333],{}," with its size (typically 0.6–1 GB); ",[17,3426,19],{}," never deletes it. The old ",[17,3429,3230],{}," service wrote it as root, so ",[17,3432,3433],{},"sudo"," is usually needed (rootful Docker on Linux):",[41,3436,3438],{"className":43,"code":3437,"language":45,"meta":46,"style":46},"sudo rm -rf data\u002Follama\n",[17,3439,3440],{"__ignoreMap":46},[50,3441,3442],{"class":52,"line":53},[50,3443,3437],{},[561,3445],{},"If ",[17,3448,3333],{}," is a symbolic link (you had moved the directory elsewhere), ",[17,3451,19],{}," reports only that it is one, without naming or measuring its target. Check where it points yourself (",[17,3454,3455],{},"ls -l data\u002Follama",") before you remove anything. The old Ollama image can be removed with your engine's own image commands.",[14,3458,3459,3462],{},[403,3460,3461],{},"What the first start after the upgrade does."," It takes longer than a normal start, once:",[526,3464,3465,3472,3482],{},[529,3466,3467,3468,3471],{},"The one-shot ",[403,3469,3470],{},"re-ingests the MITRE reference data",", because its vectors changed. This takes about a minute, and the platform is not up meanwhile.",[529,3473,3474,3475,3478,3479,3481],{},"The platform ",[403,3476,3477],{},"downloads the model once"," (about 1.26 GB), unless ",[17,3480,194],{}," placed it.",[529,3483,3484,3485,3488,3489,897,3491,3493,3494,3497,3498,105],{},"It then ",[403,3486,3487],{},"embeds every class once, at about 0.2 s per class on a 4-vCPU host: seconds for the bundled modules (about 80 classes, 15–20 s), a few minutes with cloud content packages (about 1,200 classes). Matching uses names meanwhile."," This covers the classes of mounted cloud modules too. ",[17,3490,896],{},[17,3492,900],{}," until the embedder is ready, and turns ",[17,3495,3496],{},"healthy"," while the classes may still be embedding; see ",[99,3499,905],{"href":904},[14,3501,3502,3505,3506,3508,3509,3511,3512,3514],{},[403,3503,3504],{},"Resources."," The platform uses roughly 0.8–0.9 GiB more memory, because it holds the model itself; the ",[17,3507,3230],{}," container it replaces used about as much, so the host's total stays about the same. On disk, ",[17,3510,200],{}," adds about 1.26 GB, and removing ",[17,3513,3333],{}," gives back 0.6–1 GB.",[14,3516,3517,3520,3521,3523,3524,3527],{},[403,3518,3519],{},"Rolling back."," This needs what you kept in step 1: the backup, the saved ",[17,3522,96],{},", and the previous release's bundle tarball. ",[403,3525,3526],{},"Anything created since the upgrade is lost",": the restore puts the graph back as it was when you took the backup.",[1121,3529,3530,3533,3547],{},[529,3531,3532],{},"Unpack the previous tarball over the bundle directory, as in step 3 of the upgrade.",[529,3534,3535,3536,3538,3539,382,3541,3543,3544,105],{},"Restore the saved ",[17,3537,96],{},", with its ",[17,3540,3377],{},[17,3542,799],{}," lines: ",[17,3545,3546],{},"cp .env.before-\u003Cversion> .env",[529,3548,3549,3550],{},"Apply, restore the graph, and recreate the platform:",[41,3551,3553],{"className":43,"code":3552,"language":45,"meta":46,"style":46},".\u002Fbyodt update\n.\u002Fbyodt restore backups\u002F\u003Cyour backup>.snapshot\n.\u002Fbyodt restart platform\n",[17,3554,3555,3559,3564],{"__ignoreMap":46},[50,3556,3557],{"class":52,"line":53},[50,3558,3212],{},[50,3560,3561],{"class":52,"line":433},[50,3562,3563],{},".\u002Fbyodt restore backups\u002F\u003Cyour backup>.snapshot\n",[50,3565,3566],{"class":52,"line":602},[50,3567,3568],{},".\u002Fbyodt restart platform\n",[14,3570,3571,3572,3574,3575,3577,3578,3580,3581,3583],{},"Keep ",[17,3573,3333],{}," until you are sure you will not roll back: the previous release's ",[17,3576,3230],{}," service reads its model from there, and downloads it again without it. After a rollback, ",[17,3579,200],{}," (1.26 GB) is no longer used and can be removed. Its files are owned by the platform's user (uid 1001) on rootful Docker, so ",[17,3582,3433],{}," is usually needed:",[41,3585,3587],{"className":43,"code":3586,"language":45,"meta":46,"style":46},"sudo rm -rf data\u002Fmodels\n",[17,3588,3589],{"__ignoreMap":46},[50,3590,3591],{"class":52,"line":53},[50,3592,3586],{},[33,3594],{},[36,3596,3598],{"id":3597},"removing-the-deployment","Removing the deployment",[482,3600,3602],{"id":3601},"remove-the-running-deployment-keep-the-data","Remove the running deployment, keep the data",[41,3604,3606],{"className":43,"code":3605,"language":45,"meta":46,"style":46},".\u002Fbyodt destroy\n",[17,3607,3608],{"__ignoreMap":46},[50,3609,3610],{"class":52,"line":53},[50,3611,3605],{},[14,3613,3614,3615,3618,3619,3621,3622,3624,3625,2792,3627,105],{},"Removes the containers and the network. ",[403,3616,3617],{},"Nothing on disk is deleted"," — not your data, not your configuration, not your certificate. ",[17,3620,112],{}," brings it all back as it was. Like ",[17,3623,446],{},", it refuses while another folder runs the deployment, and takes ",[17,3626,128],{},[99,3628,133],{"href":132},[14,3630,3631,3632,3635,3636,3639],{},"The command then prints the exact commands to wipe the graph ",[2760,3633,3634],{},"if you want to",", correct for your storage setting — either removing the data directory, or removing the named volume with your engine. On Neo4j under rootless Podman it adds the ",[17,3637,3638],{},"podman unshare rm -rf"," form, because the database files belong to the container's user. Read what it prints; it is generated for your deployment, not a generic example.",[452,3641,3642],{},[14,3643,3644,3648],{},[403,3645,3571,3646,105],{},[17,3647,1487],{}," It holds the database password. Deleting it while the graph still exists locks you out of your own data. If you want a clean graph, delete the data and keep the password — a fresh database adopts the password already on disk.",[482,3650,3652],{"id":3651},"remove-everything","Remove everything",[1121,3654,3655,3660,3663,3671],{},[529,3656,3657],{},[17,3658,3659],{},".\u002Fbyodt destroy",[529,3661,3662],{},"Run the wipe command it printed, if you want the graph gone.",[529,3664,3665,3666,382,3668,3670],{},"Delete the bundle directory — but move ",[17,3667,214],{},[17,3669,1487],{}," out first if you might want them.",[529,3672,3673,3674,3676],{},"Remove the container images with your engine's own image commands if you want the disk space back. ",[17,3675,314],{}," lists exactly which images this deployment pinned.",[33,3678],{},[36,3680,3682],{"id":3681},"the-escape-hatch","The escape hatch",[14,3684,3685],{},"Anything the named commands do not cover:",[41,3687,3689],{"className":43,"code":3688,"language":45,"meta":46,"style":46},".\u002Fbyodt compose ps\n.\u002Fbyodt compose config\n.\u002Fbyodt compose exec platform sh\n",[17,3690,3691,3696,3701],{"__ignoreMap":46},[50,3692,3693],{"class":52,"line":53},[50,3694,3695],{},".\u002Fbyodt compose ps\n",[50,3697,3698],{"class":52,"line":433},[50,3699,3700],{},".\u002Fbyodt compose config\n",[50,3702,3703],{"class":52,"line":602},[50,3704,3705],{},".\u002Fbyodt compose exec platform sh\n",[14,3707,3708,3709,3711,3712,3714,3715,1746,3717,3714,3720,3722,3723,3725],{},"This runs your engine's ",[17,3710,23],{}," with the bundle's configuration and secret files already supplied, and with the compose files for your database engine: ",[17,3713,2637],{},", then ",[17,3716,2641],{},[17,3718,3719],{},"compose.neo4j.yaml",[17,3721,1934],{}," if you have one. That is the part that is tedious to get right by hand, and a bare ",[17,3724,23],{}," call without the engine's file has no database service.",[452,3727,3728],{},[14,3729,3730,459,3733,3736,3737,3740,3741,3744,3745,3747,3748,3751],{},[403,3731,3732],{},"The safety rails do not apply here.",[17,3734,3735],{},".\u002Fbyodt compose down -v"," will delete a named-volume graph, where ",[17,3738,3739],{},".\u002Fbyodt down -v"," refuses. The escape hatch also does not check for ",[99,3742,3743],{"href":132},"a deployment in another folder",", and never shows the ",[99,3746,1603],{"href":306},", so a ",[17,3749,3750],{},".\u002Fbyodt compose pull"," downloads without it. Use the escape hatch when you know what you are doing.",[452,3753,3755],{"className":3754},[3004,3005],[14,3756,3757,459,3759,3762],{},[403,3758,3010],{},[17,3760,3761],{},".\u002Fbyodt compose config"," prints every service's environment in full, including the database password and, if you set one, the outbound proxy's login. Do not paste its output anywhere public.",[33,3764],{},[36,3766,3768],{"id":3767},"related","Related",[526,3770,3771,3778,3783],{},[529,3772,3773,3777],{},[99,3774,3776],{"href":3775},"\u002Fbyodt-cloud\u002Fconfiguration","Configuration"," — every setting, and which command applies it.",[529,3779,3780,3782],{},[99,3781,1365],{"href":1364}," — connecting the deployment to sign-in and content packages.",[529,3784,3785,3787],{},[99,3786,3275],{"href":3274}," — symptom, cause, and fix.",[3789,3790,3791],"style",{},"html .default .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}html .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}html .dark .shiki span {color: var(--shiki-dark);background: var(--shiki-dark-bg);font-style: var(--shiki-dark-font-style);font-weight: var(--shiki-dark-font-weight);text-decoration: var(--shiki-dark-text-decoration);}html.dark .shiki span {color: var(--shiki-dark);background: var(--shiki-dark-bg);font-style: var(--shiki-dark-font-style);font-weight: var(--shiki-dark-font-weight);text-decoration: var(--shiki-dark-text-decoration);}",{"title":46,"searchDepth":602,"depth":602,"links":3793},[3794,3795,3798,3799,3805,3806,3812,3820,3845,3849,3850],{"id":38,"depth":433,"text":39},{"id":419,"depth":433,"text":420,"children":3796},[3797],{"id":484,"depth":602,"text":133},{"id":575,"depth":433,"text":576},{"id":645,"depth":433,"text":646,"children":3800},[3801,3802,3803,3804],{"id":649,"depth":602,"text":650},{"id":712,"depth":602,"text":713},{"id":748,"depth":602,"text":749},{"id":803,"depth":602,"text":804},{"id":821,"depth":433,"text":822},{"id":910,"depth":433,"text":911,"children":3807},[3808,3809,3810,3811],{"id":914,"depth":602,"text":915},{"id":975,"depth":602,"text":976},{"id":1083,"depth":602,"text":1084},{"id":1097,"depth":602,"text":1098},{"id":1188,"depth":433,"text":1189,"children":3813},[3814,3815,3816,3817,3818,3819],{"id":1202,"depth":602,"text":1203},{"id":1227,"depth":602,"text":1228},{"id":1274,"depth":602,"text":1275},{"id":1292,"depth":602,"text":1293},{"id":1336,"depth":602,"text":1337},{"id":1354,"depth":602,"text":1355},{"id":1370,"depth":433,"text":187,"children":3821},[3822,3824,3825,3826,3827,3828,3829,3830,3831,3832,3833,3834,3843],{"id":1420,"depth":602,"text":3823},"Upgrade with .\u002Fbyodt upgrade",{"id":1538,"depth":602,"text":1539},{"id":1791,"depth":602,"text":1792},{"id":1960,"depth":602,"text":1568},{"id":2142,"depth":602,"text":2143},{"id":2176,"depth":602,"text":1926},{"id":2385,"depth":602,"text":2386},{"id":2472,"depth":602,"text":2473},{"id":2508,"depth":602,"text":1408},{"id":2598,"depth":602,"text":1412},{"id":2799,"depth":602,"text":2796},{"id":2938,"depth":602,"text":1417,"children":3835},[3836,3837,3838,3839,3841,3842],{"id":2972,"depth":608,"text":2973},{"id":2988,"depth":608,"text":2989},{"id":3023,"depth":608,"text":3024},{"id":3069,"depth":608,"text":3840},"4. Bring .env into line with the new .env.example",{"id":3208,"depth":608,"text":3209},{"id":3248,"depth":608,"text":3249},{"id":3278,"depth":602,"text":3844},"Upgrading from a release with the ollama service",{"id":3597,"depth":433,"text":3598,"children":3846},[3847,3848],{"id":3601,"depth":602,"text":3602},{"id":3651,"depth":602,"text":3652},{"id":3681,"depth":433,"text":3682},{"id":3767,"depth":433,"text":3768},"The byodt command reference and the day-to-day tasks: start, stop, inspect, back up, restore, TLS, upgrade, remove","md",{"category":3854,"position":608,"tags":3855},"documentation",[19,3856,3857,509,3858,359,3859],"deployment","operations","tls","cli",true,"\u002Fbyodt-cloud\u002Foperations",{"title":5,"description":3851},"02.byodt-cloud\u002F03.operations","vA63J6m7PHcKU4YidZpVq1UsBQkFjaPHLNBOw3uPCiM",[3866,3921,3949,4004,4038,4082,4097,4167],{"title":3867,"description":3868,"path":3869,"stem":3870,"children":3871,"page":-1},"Platform","Modelling, analysis, findings and controls in the Dethernety platform.","\u002Fplatform","01.platform",[3872,3876,3881,3886,3891,3896,3901,3906,3911,3916],{"title":3873,"path":3869,"stem":3874,"description":3875},"Dethernety User Documentation","01.platform\u002Findex","User guide for the Dethernety threat modeling platform",{"title":3877,"path":3878,"stem":3879,"description":3880},"Quick Start","\u002Fplatform\u002Fquick-start","01.platform\u002F01.quick-start","Install Dethernety on your own machine, draw a four-element model and read its first threat finding.",{"title":3882,"path":3883,"stem":3884,"description":3885},"Building Your First Model","\u002Fplatform\u002Fbuilding-your-first-model","01.platform\u002F02.building-your-first-model","Build a threat model of an online store in about 30 minutes, run a Threat Report on it, and raise an issue from a finding.",{"title":3887,"path":3888,"stem":3889,"description":3890},"Security Analysis Workflow","\u002Fplatform\u002Fsecurity-analysis-workflow","01.platform\u002F03.security-analysis-workflow","How to run security analysis and interpret results to improve your threat models.",{"title":3892,"path":3893,"stem":3894,"description":3895},"Managing Findings","\u002Fplatform\u002Fmanaging-findings","01.platform\u002F04.managing-findings","Record decisions on system-generated exposures and countermeasures — affirm them as confirmed live risk, or mute them as not applicable, false positive, waived, or superseded — instead of deleting them.",{"title":3897,"path":3898,"stem":3899,"description":3900},"Working with Security Controls","\u002Fplatform\u002Fworking-with-security-controls","01.platform\u002F05.working-with-security-controls","Learn how to create, manage, and assign reusable security controls in Dethernety to protect your threat models.",{"title":3902,"path":3903,"stem":3904,"description":3905},"Issue Management Guide","\u002Fplatform\u002Fissue-management-guide","01.platform\u002F06.issue-management-guide","Issue tracking, filtering, and management in Dethernety.",{"title":3907,"path":3908,"stem":3909,"description":3910},"Boundary Trust Zones","\u002Fplatform\u002Fboundary-trust-zones","01.platform\u002F07.boundary-trust-zones","Record each security boundary's trust zone, business domains, operational role, and approved channels to document how your system is meant to be segmented.",{"title":3912,"path":3913,"stem":3914,"description":3915},"Understanding Modules","\u002Fplatform\u002Funderstanding-modules","01.platform\u002F08.understanding-modules","How Dethernety's module system extends your threat modeling capabilities.",{"title":3917,"path":3918,"stem":3919,"description":3920},"Component Configuration Guide","\u002Fplatform\u002Fcomponent-configuration-guide","01.platform\u002F09.component-configuration-guide","Detailed guide on configuring different types of components and their security implications.",{"title":3922,"description":3923,"path":3924,"stem":3925,"children":3926,"page":-1},"BYODt cloud","Deploying the platform yourself and connecting it to the BYODt cloud.","\u002Fbyodt-cloud","02.byodt-cloud",[3927,3931,3936,3940,3941,3945],{"title":3928,"path":3924,"stem":3929,"description":3930},"BYODt Deployment","02.byodt-cloud\u002Findex","Run Dethernety on your own machine: install, configure, operate, and recover",{"title":3932,"path":3933,"stem":3934,"description":3935},"Installing the BYODt Deployment","\u002Fbyodt-cloud\u002Finstallation","02.byodt-cloud\u002F01.installation","Install Dethernety on your own machine: check the requirements, download and verify the signed bundle, start it, and confirm the deployment is healthy",{"title":3937,"path":3775,"stem":3938,"description":3939},"Configuring the BYODt Deployment","02.byodt-cloud\u002F02.configuration","The .env settings reference, the generated secret file, database storage, and how to apply a change",{"title":5,"path":3861,"stem":3863,"description":3851},{"title":3942,"path":1364,"stem":3943,"description":3944},"Connecting the BYODt Deployment to the Cloud","02.byodt-cloud\u002F04.cloud","Add cloud sign-in and content packages from the operator console, and disconnect again",{"title":3946,"path":3274,"stem":3947,"description":3948},"Troubleshooting the BYODt Deployment","02.byodt-cloud\u002F05.troubleshooting","Symptom, cause, and fix for the failures this deployment reports",{"title":3950,"description":3951,"path":3952,"stem":3953,"children":3954,"page":-1},"Dethereal","The Claude Code plugin: build a threat model in conversation and publish it to the platform.","\u002Fdethereal","03.dethereal",[3955,3959,3964,3969,3974,3979,3984,3989,3994,3999],{"title":3956,"path":3952,"stem":3957,"description":3958},"Dethereal — Claude Code Plugin for Threat Modeling","03.dethereal\u002Findex","Comprehensive documentation for the Dethereal threat modeling plugin",{"title":3960,"path":3961,"stem":3962,"description":3963},"Getting Started with Dethereal","\u002Fdethereal\u002Fgetting-started","03.dethereal\u002F01.getting-started","Install the plugin, authenticate, and create your first threat model",{"title":3965,"path":3966,"stem":3967,"description":3968},"The 11-Step Guided Workflow","\u002Fdethereal\u002Fguided-workflow","03.dethereal\u002F02.guided-workflow","Complete walkthrough of the \u002Fdethereal:threat-model guided process",{"title":3970,"path":3971,"stem":3972,"description":3973},"Command Reference","\u002Fdethereal\u002Fcommand-reference","03.dethereal\u002F03.command-reference","Complete reference for all 14 Dethereal slash commands",{"title":3975,"path":3976,"stem":3977,"description":3978},"Threat Model Concepts","\u002Fdethereal\u002Fmodel-concepts","03.dethereal\u002F04.model-concepts","Components, boundaries, data flows, classes, attributes, and quality scoring",{"title":3980,"path":3981,"stem":3982,"description":3983},"Discovery and Enrichment","\u002Fdethereal\u002Fdiscovery-and-enrichment","03.dethereal\u002F05.discovery-and-enrichment","Infrastructure scanning, security attributes, MITRE ATT&CK, credentials, and compliance",{"title":3985,"path":3986,"stem":3987,"description":3988},"Sync and Version Control","\u002Fdethereal\u002Fsync-and-version-control","03.dethereal\u002F06.sync-and-version-control","Push\u002Fpull workflow, conflict handling, git integration, and multi-model projects",{"title":3990,"path":3991,"stem":3992,"description":3993},"Review and Attack Surface Analysis","\u002Fdethereal\u002Freview-and-analysis","03.dethereal\u002F07.review-and-analysis","Quality review, attack surface summary, and platform analysis integration",{"title":3995,"path":3996,"stem":3997,"description":3998},"Agents, Tools, and Hooks","\u002Fdethereal\u002Fagents-and-architecture","03.dethereal\u002F08.agents-and-architecture","How the 5 AI agents, 22 MCP tools, and 3 lifecycle hooks work together",{"title":4000,"path":4001,"stem":4002,"description":4003},"Dethereal Glossary","\u002Fdethereal\u002Fglossary","03.dethereal\u002F09.glossary","Definitions for Dethereal-specific terminology",{"title":4005,"description":4006,"path":4007,"stem":4008,"children":4009,"page":-1},"Threat Report","The residual-risk report over a threat model: reading it, filtering it and exporting it.","\u002Fthreat-report","04.threat-report",[4010,4013,4018,4023,4028,4033],{"title":4005,"path":4007,"stem":4011,"description":4012},"04.threat-report\u002Findex","Read, filter, drill into, and export a residual-risk report over a threat model",{"title":4014,"path":4015,"stem":4016,"description":4017},"Getting Started with the Threat Report","\u002Fthreat-report\u002Fgetting-started","04.threat-report\u002F01.getting-started","Generate, open, refresh, and export a threat report over a model",{"title":4019,"path":4020,"stem":4021,"description":4022},"Reading the Report","\u002Fthreat-report\u002Freading-the-report","04.threat-report\u002F02.reading-the-report","Navigating the report, the shared visual language, and the Posture and Boundary Crossings views",{"title":4024,"path":4025,"stem":4026,"description":4027},"Understanding Coverage and Gaps","\u002Fthreat-report\u002Funderstanding-coverage","04.threat-report\u002F03.understanding-coverage","Reading the MITRE ATT&CK coverage matrix: tiers, prevent vs detect, off-grid notes, and what coverage does and does not mean",{"title":4029,"path":4030,"stem":4031,"description":4032},"Reachability and Flow Routes","\u002Fthreat-report\u002Freachability","04.threat-report\u002F04.reachability","Exploring flow routes to crown-jewel assets and between any two elements — and what the analysis does and does not model",{"title":4034,"path":4035,"stem":4036,"description":4037},"Working with Findings","\u002Fthreat-report\u002Fworking-with-findings","04.threat-report\u002F05.working-with-findings","The Residual Risk ledger, triaging findings, filtering, and the per-element Component Profile",{"title":4039,"description":4040,"path":4041,"stem":4042,"children":4043,"page":-1},"Risk assessment","The risk assessment module: the register, the reports and the method behind them.","\u002Frisk-assessment","05.risk-assessment",[4044,4048,4053,4058,4063,4068,4072,4077],{"title":4045,"path":4041,"stem":4046,"description":4047},"Dethernety Risk Assessment User Guide","05.risk-assessment\u002Findex","Dethernety Risk Assessment turns a threat model you have built on the Dethernety platform into a grounded, board-ready draft risk report. From one point-in-time assessment of your model you get a prioritized worklist, a likelihood × impact risk matrix, a security-coverage posture, ten kinds of finding, a management risk register your team authors and maintains, and audience-tiered stakeholder reports — Board, Risk Committee, and Technical — plus machine-readable data exports.",{"title":4049,"path":4050,"stem":4051,"description":4052},"FAQ and Troubleshooting","\u002Frisk-assessment\u002Ffaq","05.risk-assessment\u002F01.faq","Short answers to the questions analysts, risk managers, and compliance officers ask most often about the Risk Assessment. Each answer links to the guide that covers it in full.",{"title":4054,"path":4055,"stem":4056,"description":4057},"Findings","\u002Frisk-assessment\u002Ffindings","05.risk-assessment\u002F02.findings","A finding is a specific observation the Risk Assessment makes about your threat model. Every finding is grounded in something concrete you have declared — an element, a data flow, a trust zone, a crown jewel — and it points you at a place worth a closer look. This guide is the reference to open when you see a finding and want to know what it means and what to do about it.",{"title":4059,"path":4060,"stem":4061,"description":4062},"Getting Started","\u002Frisk-assessment\u002Fgetting-started","05.risk-assessment\u002F03.getting-started","Risk Assessment turns a threat model you have built on the Dethernety platform into a grounded, board-ready draft risk report — a prioritized worklist, a likelihood × impact matrix, a security-coverage posture, ten kinds of finding, a risk register your team authors, and audience-tiered stakeholder reports and exports.",{"title":4064,"path":4065,"stem":4066,"description":4067},"Methodology and Trust","\u002Frisk-assessment\u002Fmethodology-and-trust","05.risk-assessment\u002F04.methodology-and-trust","Every number in a Risk Assessment is meant to survive scrutiny. This chapter explains why you can trust the report and — just as importantly — what it deliberately declines to claim, so you can put it in front of your board, a regulator, or an external auditor and defend every line.",{"title":4019,"path":4069,"stem":4070,"description":4071},"\u002Frisk-assessment\u002Freading-the-report","05.risk-assessment\u002F05.reading-the-report","The Risk Assessment turns your threat model into a single, scannable draft risk report: an executive summary at the top and a set of analytical tabs below it. This guide explains how to read what you see — what a matrix cell means, how coverage is stated, what a severity band is (and is not), and how to interpret each tab.",{"title":4073,"path":4074,"stem":4075,"description":4076},"Stakeholder Reports and Exports","\u002Frisk-assessment\u002Fstakeholder-reports","05.risk-assessment\u002F06.stakeholder-reports","One assessment produces reporting for every audience you answer to. From a single generated Risk Assessment you can hand your board a one-page brief, give your risk committee the full reconciliation, keep the complete technical detail for your own team, and export the underlying data into your GRC tool — without ever re-running anything or reconciling one document against another.",{"title":4078,"path":4079,"stem":4080,"description":4081},"The Risk Register","\u002Frisk-assessment\u002Fthe-risk-register","05.risk-assessment\u002F07.the-risk-register","The Risk Register is where your team records and manages the real risks your organisation is carrying — on top of, but separate from, what the analysis computed for you. Each entry is written by a person: a plain-language risk statement, your own assessment of how likely it is and how much it would hurt, the findings and elements from the analysis that back it up, a treatment decision, an owner, a review date, and a reference handle you can quote in a ticket or a board pack.",{"title":4083,"description":4084,"path":4085,"stem":4086,"children":4087,"page":-1},"Threat Patterns","The Threat Patterns module and its modelling checklist.","\u002Fthreat-patterns","06.threat-patterns",[4088,4092],{"title":4089,"path":4085,"stem":4090,"description":4091},"Threat Patterns User Guide","06.threat-patterns\u002Findex","Threat Patterns finds threats in your model that no single element shows on its own. Each one appears only when several elements line up. For example, an agent may read content anyone can write, hold private data, and be able to send data where an outsider reads it. Each element can look acceptable alone, but together they form a path an attacker can use.",{"title":4093,"path":4094,"stem":4095,"description":4096},"Modelling Checklist","\u002Fthreat-patterns\u002Fmodelling-checklist","06.threat-patterns\u002F01.modelling-checklist","Threat Patterns decides a leg only from what your model states. An unanswered attribute or field is undetermined, never read as \"no\". This checklist lists the facts and drawings the analysis asks for most often. For each one it says where to set it and which leg it settles. Attribute names are shown as they appear on the class, in code.",{"title":4098,"description":4099,"path":4100,"stem":4101,"children":4102,"page":-1},"Agentic modelling","A hands-on training: model one agentic system step by step, with Threat Patterns after each step.","\u002Fagentic-modelling","07.agentic-modelling",[4103,4107,4112,4117,4122,4127,4132,4137,4142,4147,4152,4157,4162],{"title":4104,"path":4100,"stem":4105,"description":4106},"Model an Agentic Architecture","07.agentic-modelling\u002Findex","A hands-on training in modelling systems that run AI agents, so that Threat Patterns can analyse them. You build one system, a fictional customer-support copilot, in eleven short lessons. Each lesson adds one thing to the model, and you run Threat Patterns after each one to see what the change did.",{"title":4108,"path":4109,"stem":4110,"description":4111},"Lesson 1: Draw the Agent and What It Talks To","\u002Fagentic-modelling\u002F01-draw-the-agent","07.agentic-modelling\u002F01.01-draw-the-agent","Training overview · Lesson 1 of 11 · Next: Say what data moves",{"title":4113,"path":4114,"stem":4115,"description":4116},"Lesson 2: Say What Data Moves","\u002Fagentic-modelling\u002F02-say-what-data-moves","07.agentic-modelling\u002F02.02-say-what-data-moves","Training overview · Lesson 2 of 11 · Previous: Draw the agent · Next: Mark who is outside",{"title":4118,"path":4119,"stem":4120,"description":4121},"Lesson 3: Mark Who Is Outside","\u002Fagentic-modelling\u002F03-mark-who-is-outside","07.agentic-modelling\u002F03.03-mark-who-is-outside","Training overview · Lesson 3 of 11 · Previous: Say what data moves · Next: Draw a tool that reaches any host",{"title":4123,"path":4124,"stem":4125,"description":4126},"Lesson 4: Draw a Tool That Reaches Any Host","\u002Fagentic-modelling\u002F04-draw-a-tool-that-reaches-any-host","07.agentic-modelling\u002F04.04-draw-a-tool-that-reaches-any-host","Training overview · Lesson 4 of 11 · Previous: Mark who is outside · Next: State what the agent can do",{"title":4128,"path":4129,"stem":4130,"description":4131},"Lesson 5: State What the Agent Can Do","\u002Fagentic-modelling\u002F05-state-what-the-agent-can-do","07.agentic-modelling\u002F05.05-state-what-the-agent-can-do","Training overview · Lesson 5 of 11 · Previous: Draw a tool that reaches any host · Next: Fix a finding with a fact",{"title":4133,"path":4134,"stem":4135,"description":4136},"Lesson 6: Fix a Finding With a Fact","\u002Fagentic-modelling\u002F06-fix-a-finding-with-a-fact","07.agentic-modelling\u002F06.06-fix-a-finding-with-a-fact","Training overview · Lesson 6 of 11 · Previous: State what the agent can do · Next: Record a compensating control",{"title":4138,"path":4139,"stem":4140,"description":4141},"Lesson 7: Record a Compensating Control","\u002Fagentic-modelling\u002F07-record-a-compensating-control","07.agentic-modelling\u002F07.07-record-a-compensating-control","Training overview · Lesson 7 of 11 · Previous: Fix a finding with a fact · Next: Leave what you don't know open",{"title":4143,"path":4144,"stem":4145,"description":4146},"Lesson 8: Leave What You Don't Know Open","\u002Fagentic-modelling\u002F08-leave-unknowns-open","07.agentic-modelling\u002F08.08-leave-unknowns-open","Training overview · Lesson 8 of 11 · Previous: Record a compensating control · Next: Follow a credential",{"title":4148,"path":4149,"stem":4150,"description":4151},"Lesson 9: Follow a Credential","\u002Fagentic-modelling\u002F09-follow-a-credential","07.agentic-modelling\u002F09.09-follow-a-credential","Training overview · Lesson 9 of 11 · Previous: Leave what you don't know open · Next: Watch what gets into knowledge and memory",{"title":4153,"path":4154,"stem":4155,"description":4156},"Lesson 10: Watch What Gets Into Knowledge and Memory","\u002Fagentic-modelling\u002F10-what-gets-in","07.agentic-modelling\u002F10.10-what-gets-in","Training overview · Lesson 10 of 11 · Previous: Follow a credential · Next: Draw tools from others and hand-offs",{"title":4158,"path":4159,"stem":4160,"description":4161},"Lesson 11: Draw Tools From Others and Hand-offs","\u002Fagentic-modelling\u002F11-tools-and-handoffs","07.agentic-modelling\u002F11.11-tools-and-handoffs","Training overview · Lesson 11 of 11 · Previous: Watch what gets into knowledge and memory",{"title":4163,"path":4164,"stem":4165,"description":4166},"The recipe at a glance","\u002Fagentic-modelling\u002Frecipe-at-a-glance","07.agentic-modelling\u002F12.recipe-at-a-glance","The ten steps of the training on one page. Each lesson teaches one or two of them.",{"title":4168,"description":4169,"path":4170,"stem":4171,"children":4172,"page":-1},"BYODt subscription","Subscribing on the BYODt Portal, and moving a deployment you already run to a new team.","\u002Fbyodt-subscription","08.byodt-subscription",[4173,4177,4182],{"title":4174,"path":4170,"stem":4175,"description":4176},"BYODt Subscription","08.byodt-subscription\u002Findex","Buy content for the deployment you run yourself, and decide where that deployment goes when you buy a team edition",{"title":4178,"path":4179,"stem":4180,"description":4181},"Your Subscription","\u002Fbyodt-subscription\u002Fyour-subscription","08.byodt-subscription\u002F01.your-subscription","Create an account, subscribe by card, and find the values your deployment needs on the portal",{"title":4183,"path":4184,"stem":4185,"description":4186},"Moving a Deployment to a New Team","\u002Fbyodt-subscription\u002Fmoving-a-deployment-to-a-new-team","08.byodt-subscription\u002F02.moving-a-deployment-to-a-new-team","What to do with the deployment you already run once you buy a team edition: three ways forward, best first",1793748185407]