1import{J as b}from"./DIIOkCvK.js";const g=Object.fromEntries(Object.entries(b.marketing.pages).map(([i,c])=>{const a=i.startsWith("module")?"modules":i.startsWith("comparison")?"comparison":i.startsWith("resource")?"solutions":"platform";return[i,{navKey:a,eyebrow:c.eyebrow,title:c.title,lead:c.lead,highlights:c.highlights,sections:Object.entries(c.sections).map(([n,l])=>({...l,id:n})),cta:{title:"Try the workflow on a device you can reach.",copy:"Connect one Linux device and open its terminal. Choose a paid plan for diagnostics, Pulse and the operating capabilities you need.",primaryLabel:"Connect a device",primaryTo:"/login",secondaryLabel:"Find your starting point",secondaryTo:"/lifecycle"}}]})),s=(i,c,a,n)=>({id:i,title:c,subtitle:a,items:n}),t=(i,c,a)=>({title:i,copy:c,...a?{to:a,linkLabel:a.startsWith("https://docs.")?"Open the guide":"Explore this capability"}:{}}),d=(i,c,a,n,l="Compare plans",u="/pricing")=>({title:i,copy:c,primaryLabel:a,primaryTo:n,secondaryLabel:l,secondaryTo:u}),y={title:"What the connection needs",subtitle:"Install the agent on a supported Linux device you can access. Live remote access begins when the agent is online and can reach Dataplicity. Outbound network policies still apply.",items:[{label:"Installed Linux agent",icon:"linux",status:"required"},{label:"Outbound access to Dataplicity",icon:"network",status:"required"},{label:"Inbound SSH port",icon:"port",status:"not_needed"},{label:"Customer VPN",icon:"vpn",status:"not_needed"},{label:"Static public IP",icon:"network",status:"not_needed"}],benefits:[{title:"Connect from the device",copy:"The agent makes the outbound connection, including from behind NAT or a cellular network when policy permits it.",icon:"network"},{title:"Use the browser",copy:"Select an online device and open its remote terminal with the appropriate account access.",icon:"terminal"},{title:"Review access events",copy:"Session opens are recorded. Terminal contents and keystrokes are not recorded.",icon:"history"}]},m={platformRemoteOps:{...g.platformRemoteOps,translationKey:"remoteAccessV2",heroVisual:"terminal",requirements:y},moduleTerminal:{...g.moduleTerminal,translationKey:"terminalV2",heroVisual:"terminal",requirements:y},resourceIntegrations:{navKey:"solutions",translationKey:"integratedWorkflowsV2",eyebrow:"Fleet investigation",title:"Investigate devices that go offline together.",lead:"A group of devices loses connectivity at the same time. Work from the affected devices, their shared network and the evidence available to decide what to check next.",highlights:["Worked reference scenario; test the conditions and routing on your own fleet.","An offline device cannot provide a live terminal session. Use collected history until it reconnects.","Incident handling and on-call escalation require Business+."],sections:[s("scenario","Identify the affected group.","Start with what the devices have in common, rather than assuming that every offline device has the same cause.",[t("Check the time window","Compare the last check-ins. Separate a simultaneous loss of connectivity from devices that were already offline."),t("Compare shared dependencies","Group the affected devices by site, carrier or product type using the metadata your team maintains. Check whether devices outside the group are still online.")]),s("device-hunt","Review what is known about the devices.","Use the device record and collected history to choose the next useful check.",[t("Find the responsible people","Check the customer, site and assigned owner. Identify who can check a local network, account or power supply if the device remains unreachable."),t("Look for a recent change","Review available logs, check-ins and recorded changes around the outage. Missing connectivity is evidence of a symptom, not proof of a carrier fault.")]),s("integrated-response","Act, communicate and check recovery.","Keep the investigation tied to the affected equipment and verify the result.",[t("Record the response","Use Business+ incident handling to keep ownership and investigation notes together. Publish a customer status update when appropriate."),t("Investigate after reconnection","Once the agent is online, use remote access and fresh diagnostics to check the service. Verify that the affected group recovers, not just one device.","/platform/remote-access")])],cta:d("Work through the network outage playbook.","Follow the detailed investigation, then test a representative condition and notification route on your own fleet.","Open the network outage playbook","/solutions/network-outages","Compare operating plans","/pricing")},customerApplications:{navKey:"platform",translationKey:"customerApplicationsV1",eyebrow:"For your customers",title:"Give customers their devices, data and controls in your brand.",lead:"If you sell connected Linux hardware and do not want to build the customer SaaS around it from scratch, use Dataplicity for the shared device, customer and application layer. Give customers a branded view of their equipment, readings and permitted actions, then add records and workflows for jobs such as scheduling or outload. Your engineers keep the tools to operate and support the hardware.",highlights:["Keep your device softw
1are and hardware.","Start with a customer device view or build a wider product workflow.","Fleet operations remain useful whether or not you add an application."],heroVisual:"portal",sections:[s("choose-the-job","Start with the job your customer needs to do.","A branded portal is the customer entrance. A Product Application defines the records, pages and workflows inside it.",[t("Devices, readings and controls","Give a customer a useful view of their equipment, its readings and the actions they are allowed to take."),t("Records and workflows","Build around a site task: manage schedules, review events or work through an outload process. Define the data and behaviour the task requires."),t("An application you already have","Keep it. Use Dataplicity for your engineering and support team without rebuilding the customer experience.","/fleet-operations")]),s("responsibilities","What you build. What Dataplicity provides.","Building the application takes product engineering. The platform supplies the shared machinery; your team defines what the product does.",[t("Your device integration","Your team supplies the hardware, sensing, runtime and command handlers. Define the telemetry and controls your product exposes, including safety checks on the device."),t("Your customer experience","Configure branding, customer access and pages. For Product Applications, define records, rules and processes and connect them to your device contract."),t("The shared foundation","Dataplicity provides device identity, fleet operations, customer and site organisation, scoped customer access, and the application authoring and publishing system.")]),s("worked-example","Follow one customer job through the system.","Worked SiloSentry reference scenario. This explains the operating model; it is not evidence of an unrelated customer deployment.",[t("1. A reading reaches the product","A probe and gateway report a silo reading. Your sensing stack owns measurement and calibration."),t("2. The customer decides what to do","The customer sees their silo levels and attention state in the branded application. Their view is scoped to the equipment and site they can access."),t("3. Your team supports the equipment","When a reading or gateway needs investigation, engineers use device health, collected logs and remote access. Verify fresh readings after an intervention.","https://docs.dataplicity.com/product/build-a-level-monitor-product")]),s("build-and-release","Prove one customer workflow before expanding.","The integration effort depends on your device interface, data model and workflow. A working example gives your engineers a concrete starting point.",[t("Connect and define","Connect a representative device. Define its Device Class and the readings and actions required by the customer job."),t("Build and test","Build the customer pages and workflow. Check permissions with separate customer accounts and test device failures and lost connectivity. Offline behaviour needs explicit design."),t("Publish and operate","Publish a version and run it for a customer in a Product Instance. Test later changes with representative data and devices before moving customers to another version.","https://docs.dataplicity.com/product/product-applications")]),s("plans","Choose the customer scope you need.","Both paid plans can also be used for fleet operations without a customer application.",[t("One customer on Standard","One Customer Portal and one downstream customer organisation, with portal branding. Use the published limits to check the fit."),t("Multiple customers on Business+","Multiple portals and customer organisations, subject to platform limits, alongside advanced operating capabilities.","/pricing")])],cta:d("Inspect a complete application before planning your own.","Follow the level-monitor walkthrough from the device contract to the customer view. Then use the Product Applications guide to map the work for your product.","Follow the application walkthrough","https://docs.dataplicity.com/product/build-a-level-monitor-product","Explore Product Applications","https://docs.dataplicity.c
1om/product/product-applications")},lifecycle:{navKey:"platform",translationKey:"lifecycleV1",eyebrow:"Find your starting point",title:"Start with a prototype, a batch or an existing fleet.",lead:"You can start with a prototype, a production run or equipment already in the field. Choose the problem you need to solve. Keep the hardware, application and customer relationships you already have.",highlights:["Join at any stage.","Operate devices for as long as you need, with no customer portal required.","Add customer applications only when they serve your product."],sections:[s("prototype","A device on your desk","First prove you can reach and investigate a real device.",[t("Open its terminal remotely","Connect one device and open its Linux terminal through the outbound agent connection.","/modules/terminal"),t("Investigate a fault first","Use public Device Check for a temporary diagnostic report without an account. You need a way to run its command on the device.","/device-check")]),s("production","Your first pilot or production batch","Make support repeatable before each unit becomes a special case.",[t("Repeat the installation","Use an organisation-specific installation process and Device Classes. Verify identity and first check-in on a representative batch.","/platform/provisioning"),t("Check the pilot before expanding","Compare collected errors across a firmware cohort and investigate a suspect release before proceeding.","/solutions/firmware-log-analytics")]),s("existing-fleet","Equipment already in the field","Improve operations alongside the software and management process you already use.",[t("Start with a reachable cohort","Install the agent through your existing remote access, update system or a planned site visit. Dataplicity access begins once that agent connects.","/fleet-operations"),t("Keep your existing application","Your device runtime and customer application can stay. See where the agent, operating workspace and optional customer application fit.","/platform/architecture")]),s("support","Support is becoming harder to manage","Give the next engineer the device context and evidence needed to pick up the work.",[t("Investigate fleet-wide trouble","Scope affected devices, compare cohorts and use the available evidence to decide the next action.","/solutions/network-outages"),t("Decide whether a site visit is needed","Bring device evidence and customer context into the support decision before dispatch or replacement.","/solutions/customer-status-warranty")]),s("customer-application","Customers need their own application","Build the customer job on the connected-device foundation.",[t("Provide their devices, data and controls","Add a branded portal and scoped access. Extend it with records and workflows where the customer task requires them.","/customer-applications")]),s("service-life","Products change hands, need replacing or reach end of service","Keep service decisions tied to the equipment. Your team defines the handover and retirement process.",[t("Preserve the service context","Keep customer, site and available service history in view when investigating an ageing or replacement unit.","/platform/customer-trust"),t("Make the handover reviewable","Track replacement or retirement work with links to devices and incidents. Include ownership checks and access review in your process.","/modules/project-boards")])],cta:d("Choose one useful result to prove.","Start with remote access to a device you can reach, or inspect a complete customer application. Neither commits you to adopting everything.","Explore fleet operations","/fleet-operations","Explore customer applications","/customer-applications")},platformArchitecture:{navKey:"platform",translationKey:"architectureV2",eyebrow:"Product architecture",title:"Keep your product. Add the operating foundation.",lead:"Your Linux device and application keep doing their job. Dataplicity supplies the post-shipment layer around them: outbound device connectivity, identity, fleet operations and optional customer-facing software. The agent connects the device to the operating workspace; a branded customer application is optional.",highlights:["An outbound agent connection on supported Linux.","Device context shared across investigation and response.","Engineering tools and customer access have distinct purposes."],sections:[s("device","On the device","Install alongside the softw
1are you run today.",[t("Your hardware and runtime","You retain the board, operating system and application, including physical integration and safety logic."),t("The Dataplicity agent","Install through an existing local, provisioning or update process. Live remote access requires an online agent and permitted outbound connectivity.","/platform/provisioning")]),s("operations","For your engineering and support team","Keep the unit in context from first investigation to follow-up.",[t("One device record","Identity, class, customer and site context help you find and group the right devices.","/platform/fleet-identity"),t("Investigate and act","Use Pulse, collected logs and diagnostics to investigate. Open a terminal or use the operating capabilities available on your plan.","/fleet-operations")]),s("customers","For your customers, when needed","Keep the application you already have, or build a customer experience on Dataplicity.",[t("Scoped customer access","Give customers their own devices, sites, readings and permitted controls in a branded portal."),t("Product workflows","Define the records, rules and processes needed for the customer job. Your engineers implement and test the device integration.","/customer-applications")])],cta:d("See how this fits your current stage.","Start with the operating gap you have today. Expand only where it is useful.","Find your starting point","/lifecycle","Explore fleet operations","/fleet-operations")},platformFleetVisibility:{navKey:"platform",translationKey:"fleetVisibilityV2",eyebrow:"Fleet visibility",title:"Find the affected devices. Then find out what changed.",lead:"Review device identity and health, compare peers with Pulse, and investigate collected logs with the fleet context in front of you.",highlights:["Useful for an existing installed base.","No customer application required.","Investigate differences before treating them as faults."],heroVisual:"fleet",sections:[s("investigate","From a fleet question to a specific next step","Worked investigation sequence. Available evidence depends on what has been collected and your plan.",[t("Scope the problem","Find the affected devices and compare their class, customer, site or cohort."),t("Review the difference","Use Pulse findings and collected logs to look for a change. Peer divergence is a reason to investigate, not proof of failure."),t("Check the result","Inspect an online device, take an appropriate action and review fresh evidence afterwards.","/fleet-operations#investigate")])],cta:d("Evaluate fleet visibility with representative devices.","One device proves remote access. Peer comparison needs comparable devices in a class and time to collect evidence. Choose a paid plan for Pulse and the investigation capabilities you need.","Explore the operating workflow","/fleet-operations","Compare plans","/pricing")},platformCustomerTrust:{navKey:"platform",translationKey:"customerTrustV2",eyebrow:"Support and service life",title:"Make the service decision with the device evidence in view.",lead:"Keep customer and site context alongside device health, logs and incidents. Help the next responder understand what happened before deciding on a remote fix, visit or replacement.",highlights:["Support the installed base without requiring a customer portal.","Keep investigation and follow-up together.","Publish only the status information customers need."],heroVisual:"customers",sections:[s("support","From the support request to the next action","Worked support scenario. A device must be online for live investigation; historical evidence is limited to what was collected.",[t("Identify the unit","Check which device and customer are affected, and review available service and coverage context."),t("Investigate before dispatch","Review logs and diagnostics. Where the device is online, inspect the service remotely before deciding whether an on-site visit is necessary.","/solutions/customer-status-warranty"),t("Leave a useful handover","Record the action, the result and the remaining work. Track a replacement or follow-up with links to the affected device and incident.","/modules/project-boards")]),s("customer-view","Give customers an appropriate view","A service-status page and a customer product application serve different jobs.",[t("Explain a service incident","Use status pages for customer-safe availability and incident updates.","/modules/status-pages"),t("Let customers operate their product","Use a branded application when customers need their own records, data and permitted controls.","/customer-applications")])],cta:d("Follow a complete support decision.","See how available device evidence informs the decision to fix remotely, dispatch or replace.","Read the support playbook","/solutions/customer-status-warranty","Explore service-life paths","/lifecycle#service-life")}
1,comparisonStatusStack:{navKey:"comparison",translationKey:"statusStackV2",eyebrow:"Operating workflow",title:"Keep the device context through the whole incident.",lead:"Access, monitoring, logs and incident tools each solve a real problem. Dataplicity brings these workflows around the same device record so responders can follow the evidence and act.",highlights:["Keep the runtime and customer application you already use.","Adopt the operating capabilities you need.","Evaluate the response workflow with a representative incident."],sections:[s("compare","Compare the handoffs your team makes today","Use a real incident to judge the fit. Existing tools may already meet part of the need.",[t("Finding the affected equipment","Can the alert take the responder to the affected devices, customer and cohort?"),t("Investigating and acting","Can they review collected logs and reach an online device without first reconstructing its identity in another tool?"),t("Following through","Can the next responder see ownership, notes and the evidence after the action?","/solutions/network-outages")])],cta:d("See the operating workflow.","Follow the device from fleet attention to investigation and follow-up.","Explore fleet operations","/fleet-operations","Find your starting point","/lifecycle")},platformCustomerSurfaces:{navKey:"platform",translationKey:"customerSurfacesV2",eyebrow:"Customer views",title:"Give each audience the view they need.",lead:"Share service status, publish a read-only dashboard, or build a customer application with permitted controls and workflows. Choose the surface around the job.",highlights:["Keep engineering tools with your team.","Scope customer access to the intended audience.","A customer application is optional for fleet operations."],sections:[s("choose","Three different jobs","Choose the smallest useful customer experience.",[t("Service status","Tell customers about availability and incidents with customer-safe updates.","/modules/status-pages"),t("Read-only visibility","Publish metrics for a customer or an internal display without giving the audience the engineering console.","/modules/dashboards"),t("A customer application","Give customers their devices, data and controls. Add records and workflows when they need to do more.","/customer-applications")])],cta:d("Explore the customer application path.","See the responsibility split and a complete worked example before planning the integration.","Explore customer applications","/customer-applications")},moduleWormhole:{navKey:"modules",translationKey:"wormholeV2",eyebrow:"Remote web access",title:"Reach a web interface running on your Linux device.",lead:"Use Wormhole to reach a device-hosted HTTP service through the outbound Dataplicity connection. Keep the device application you already run.",highlights:["No inbound forwarding rule required.","Live access requires a connected agent.","Configure access controls appropriate to the service you expose."],sections:[s("workflow","Use the web tool already on the device","Start with a reachable device and a working local HTTP service.",[t("Connect the agent","Install on supported Linux and verify that the device appears online."),t("Configure web forwarding","Point Wormhole at the intended HTTP service and review its access settings."),t("Test access","Open the address and check that only the intended service and audience have access.")])],cta:d("Connect a device and test its web interface.","Start with a device you can access locally or through an existing management process.","Connect a device","/login")}},o="https://docs.dataplicity.com",e=(i,c,a)=>({title:i,copy:c,...a?{to:a,linkLabel:a.startsWith(o)?"Read the technical guide":"Explore this path"}:{}}),r=(i,c,a,n)=>({id:i,title:c,subtitle:a,items:n}),h=(i,c,a,n)=>({title:i,copy:c,primaryLabel:a,primaryTo:n,secondaryLabel:"Compare plans",secondaryTo:"/pricing"}),S=[e("Reach and support devices","Reach Linux devices behind customer networks. Investigate with Pulse, diagnostics and collected logs without replacing the application you already run.","/fleet-operations"),e("Manage releases when you want to","Fleet operations works with the softw
1are and updater you already have. If useful, add managed application releases or RAUC fleet rollouts later.","/platform/software-lifecycle"),e("Keep essential work local","Use explicit Edge execution, selected local data and bounded buffering for products that must tolerate unreliable connectivity.","/platform/offline-edge"),e("Give customers an application","Provide scoped device views, records, controls and workflows in your brand while keeping engineering tools with your team.","/customer-applications")],f={platformSoftwareLifecycle:{navKey:"platform",translationKey:"softwareLifecycleV1",eyebrow:"Linux software delivery and RAUC OTA",title:"Release software across your Linux fleet. Know what actually happened.",lead:"Fleet operations does not require Dataplicity to own your software lifecycle. Keep the application and updater you already use. If you want more later, add managed application releases or fleet-level RAUC rollout control as separate, optional capabilities.",seoTitle:"Linux Software Deployment and RAUC OTA Updates | Dataplicity",seoDescription:"Manage Linux application releases and RAUC OS updates with Software Builds, cohorts, staged rollout, validation outcomes and rollback visibility.",highlights:["Use remote access, Pulse, diagnostics and fleet visibility without changing your updater.","Add managed application releases or RAUC OS updates only when they solve a problem for you.","When Dataplicity manages a rollout, success, rollback, failure and unresolved devices remain distinct."],sections:[r("start-existing","Start with the fleet you already have.","Software delivery is optional. Dataplicity can add an operating layer around an existing Linux product without forcing a new application packaging or OS-update strategy.",[e("Operate without changing releases","Use remote access, Pulse, diagnostics, logs and fleet visibility alongside your existing application and update mechanism.","/fleet-operations"),e("Add application releases if useful","When you want Dataplicity to manage application delivery too, use versioned Software Builds and cohorts. You do not have to containerise an existing product merely to use fleet operations.",`${o}/product/software-builds-and-cohorts`),e("Add OS rollout control if useful","If your product already uses a suitably prepared RAUC A/B image, Dataplicity can add fleet targeting, rollout control and outcome visibility. RAUC remains responsible for the device-side update and recovery chain.",`${o}/fleet-operations/manage-rauc-updates-across-a-fleet`)]),r("operator-journey","Release deliberately. See what actually happened.","When you choose Dataplicity-managed delivery, the marketing promise is an operator outcome rather than a new device architecture.",[e("Choose what changes","Keep application and OS releases distinct. Select the version you intend to deploy and the bounded cohort that should receive it."),e("Watch the rollout","See devices move through delivery and validation rather than treating a requested version as proof that it is running. Offline and unresolved devices remain visible."),e("Decide whether to continue","Separate successful, failed and rolled-back outcomes, check product health, and expand only when the observed result supports the release decision.",`${o}/product/software-delivery`)]),r("application-releases","Manage application releases without turning fleet operations into a migration project.","Software Builds are there for teams that want Dataplicity to manage this part of the lifecycle.",[e("Version the application","Use immutable versions and Software Builds to describe the application composition you want to run. Keep product-specific code and hardware integration in your application."),e("Stage by cohort","Start with test hardware or a limited production group, observe the result and promote deliberately rather than changing the entire fleet at once.",`${o}/product/software-builds-and-cohorts`)]),r("rauc","Keep RAUC on the device. Add fleet-level control around it.","Dataplicity works with a correctly prepared RAUC A/B image and adds fleet targeting, rollout control and outcome visibility. Your device remains responsible for its qualified boot and update chain.",[e("Bring an existing RAUC update path","You keep the signed image, inactive slot recovery design and recovery chain. Dataplicity adds the fleet view around it.",`${o}/fleet-operations/rauc-image-ota-requirements`),e("Control rollout from the fleet","Choose the target, follow progress and distinguish validation, rollback, failure, offline and unknown outcomes. Resume or expand as an explicit operator decision.",`${o}/fleet-operations/manage-rauc-updates-across-a-fleet`),e("Keep integration detail in the technical guide","Bootloader integration, slots, signing, certificates, image preparation and device qualification are important engineering requirements. They belong in the RAUC integration guide rather than being prerequisites for understanding the product page.",`${o}/fleet-operations/rauc-image-ota-requirements`)]),r("failure","A rollout is useful only if failure is understandable.","The operating surface should help the team decide what to do next, not collapse every non-success into silence.",[e("Offline is not failed","A device that has not reported an outcome remains unresolved. Keep it separate from a device that attempted the release and failed."),e("Rollback is an outcome","Show that the device recovered to the previous known-good state rather than reporting the attempted release as successful."),e("Product health matters","A booted Linux device is not automatically a healthy product.
1Verify the signals that matter to the equipment before expanding a release.",`${o}/fleet-operations/verify-rauc-rollout-outcome`)]),r("evaluate","Prove the operating workflow on a small part of your fleet.","Use representative equipment and the release mechanism you actually intend to operate.",[e("Start with one useful change","Connect representative hardware, establish its current state and release to a bounded cohort."),e("Include an imperfect outcome","Exercise an offline or deliberately failed test device so the team can see how unresolved and recovery states appear."),e("Expand only after evidence","Confirm the running version and product health, then decide whether the release should continue.",`${o}/fleet-operations/verify-rauc-rollout-outcome`)])],cta:h("Evaluate the release path that your product actually needs.","Start with container Builds or a qualified RAUC device. Use the requirements and operating guides to define a bounded evaluation before changing the installed base.","Read the RAUC fleet guide",`${o}/fleet-operations/manage-rauc-updates-across-a-fleet`)},platformOfflineEdge:{navKey:"platform",translationKey:"offlineEdgeV1",eyebrow:"Offline and edge operation",title:"Keep essential work local when the connection drops.",lead:"Dataplicity supports explicit local Process execution, selected offline datasets and bounded data delivery around connected Linux products. Decide which work must continue on the device and which work can wait for the cloud. Your existing daemon or container still owns the hardware interface and physical safety.",seoTitle:"Offline IoT and Edge Workflows for Linux Devices | Dataplicity",seoDescription:"Design Linux products for intermittent connectivity with explicit Edge Processes, local datasets, bounded buffering, command expiry and reconnect handling.",highlights:["Cloud, Edge and Mixed execution are deliberate choices, not transparent failover.","Live remote access needs connectivity; essential local behaviour must not.","Buffered, delivered and physically completed are different states."],sections:[r("outcome","Decide what must still work without the cloud.","Offline operation is a product decision first. Dataplicity gives you explicit places to run local work and reconcile it later; it does not pretend every cloud function transparently survives an outage.",[e("Keep the essential job local","Put only the work that must continue through an outage on the device. Your existing service or container can remain responsible for hardware and safety."),e("Let cloud work wait","Central records, integrations and cross-device coordination can remain cloud-side. Make waiting, expiry and unavailable states visible rather than disguising them as success."),e("Mix the two deliberately","Use a local segment where the customer job requires it and reconnect it to the cloud workflow when connectivity returns.",`${o}/product/choose-process-placement`)]),r("outage","Make the outage understandable to operators and customers.","Local work, buffered data, pending requests and live access have different behaviours.",[e("Local work can continue","Previously deployed local logic and selected data can keep an approved product function running within the authority and limits you define."),e("Data can wait for delivery","Eligible device data can be retained within documented bounds and sent after reconnect. Critical product records still need the durability policy appropriate to the application.",`${o}/product/device-data-and-control-contract`),e("Requests are not physical outcomes","Show a setting or command as pending until the device reports what actually happened. Expired, rejected and uncertain work should remain distinguishable.",`${o}/product/what-happens-when-a-device-is-offline`),e("Live access waits","Remote Shell and other live device interactions need connectivity. Keep last-seen and data age visible while the device is away.")]),r("example","Follow one customer job through a lost connection.","Illustrative evaluation scenario, not a customer deployment.",[e("Before the outage","Deploy the schedule or local behaviour while connected and confirm what the device has actually applied."),e("During the outage","The approved local job continues. Cloud-only changes and live support wait, while eligible observations are retained within their configured bounds."),e("Reconnected","After reconnect, resume delivery, reconcile the reported outcome and surface anything still uncertain instead of assuming queued work completed.",`${o}/product/what-happens-when-a-device-is-offline`)]),r("integration","Keep the device softw
1are you already trust.","Dataplicity can work around ordinary device code as well as managed components.",[e("Existing daemon or container","Your service can continue to own protocols, drivers and physical behaviour while exchanging product data and permitted actions with Dataplicity.",`${o}/product/device-data-and-control-contract`),e("Managed Edge Process when useful","Use local Process execution for bounded product workflow that benefits from the shared application model. It is an option, not a requirement for offline-aware fleet operations.",`${o}/product/choose-process-placement`),e("Keep safety local","Hard real-time protection, emergency behaviour and irreversible physical safety remain responsibilities of qualified local product software.")]),r("evaluate","Test the customer-visible behaviour, not just the network failure.","A useful offline test proves what continues, what waits and what the user sees.",[e("Disconnect deliberately","Confirm the essential local job continues and cloud-dependent work becomes visibly pending or unavailable."),e("Restart and reconnect","Exercise the recovery path and confirm retained information is reconciled without silently duplicating physical work."),e("Inspect uncertain states","Verify stale readings, expired work and unresolved outcomes remain explicit.",`${o}/product/production-limits`)])],cta:h("Map one customer job across connected and disconnected operation.","Choose the local work, cloud dependencies and recovery policy first. Then verify the documented runtime and delivery contracts on representative hardware.","Read the execution placement guide",`${o}/product/choose-process-placement`)},comparisonBuyingGuide:{navKey:"comparison",translationKey:"comparisonBuyingGuideV1",eyebrow:"Compare adoption paths",title:"Choose the parts you need. Keep the parts that already work.",lead:"Compare Dataplicity with qbee, balena, Mender, Losant, Tailscale and AWS IoT around the job you need to finish. Dataplicity combines Linux fleet operations with optional customer applications; that does not mean every buyer should replace an existing updater, network or cloud stack.",seoTitle:"Dataplicity vs qbee, balena, Mender and Losant",seoDescription:"Compare Linux fleet operations, RAUC software delivery, offline workflows and customer applications by adoption effort and responsibility, not feature checkmarks.",highlights:["Compare the complete operating workflow, not only matching feature names.","Evaluate overlap honestly; another platform may already meet the requirement.","Keep one system authoritative for each update, configuration and physical action."],sections:[r("existing-stack","Start with the system you already have.","Evaluate the gap you need to close. A Dataplicity adoption does not have to be a platform replacement.",[e("We already have device access","Keep it if it solves the job. Evaluate Dataplicity where fleet visibility, diagnosis and support workflow are the missing pieces.","/fleet-operations"),e("We already have an updater","Keep a working updater while evaluating fleet operations. Add Dataplicity-managed application or RAUC rollout only if the additional control and outcome visibility is useful.","/platform/software-lifecycle"),e("We already have a customer application","Retain it and evaluate device operations independently. Add Dataplicity customer applications only where they remove SaaS work you would otherwise own.","/customer-applications")]),r("named-comparisons","Compare the job each alternative is designed to do.","These are starting points for a buying decision. The technical guides hold the detailed feature and architecture comparisons.",[e("qbee","Compare Linux fleet operations, configuration and software delivery. If RAUC is central, both products can participate in that lifecycle; compare the operating workflow around it.",`${o}/product/dataplicity-vs-qbee`),e("balena","Compare adopting a container-centric device platform with adding fleet services around an existing supported Linux product.",`${o}/product/dataplicity-vs-balena`),e("Mender","Compare an OTA-centred lifecycle with the broader fleet and customer-application responsibilities you need to cover.",`${o}/product/dataplicity-vs-mender`),e("Losant and application platforms","Compare the customer application and workflow you need to deliver, then include how engineering operates the underlying Linux equipment.",`${o}/product/dataplicity-vs-iot-application-platforms`),e("Tailscale","Compare private networking with a device-focused operating workspace. If networking alone solves the requirement, keep the smaller solution.",`${o}/product/dataplicity-vs-tailscale`),e("AWS IoT and Greengrass","Compare assembling cloud and edge building blocks with adopting shared fleet and customer-product services.",`${o}/product/dataplicity-vs-aws-iot-greengrass`)]),r("evaluation","Test the same real job on the shortlist.","Keep the marketing comparison simple; use the technical guides when you need protocol, architecture and implementation detail.",[e("Operate the device","Connect representative hardware, diagnose a fault and see whether the workflow leaves the operator knowing what happened.","/fleet-operations"),e("Handle change and disconnection","Release only if lifecycle management matters to you; disconnect a test device and inspect what remains known, pending or unavailable.","/platform/offline-edge"),e("Complete the customer task","If a customer application is part of the requirement, use separate test customers and complete one real product task end to end.","/customer-applications")]),r("when-not","A larger platform is not automatically the better fit.","Choose the smallest approach that meets the complete requirement.",[e
1("Keep a specialist that already works","If your updater, network or application platform meets the requirement at an acceptable operating cost, retain it. Evaluate Dataplicity on a concrete missing capability."),e("Know the product boundary","Dataplicity does not replace product-specific sensing, hardware safety, every external business system or unrestricted bespoke software.",`${o}/product/what-does-dataplicity-replace`)])],cta:h("Make the decision with your product in view.","Read the technical comparison for your starting point, then prove one useful operating or customer workflow. Check current limits and plan entitlements before expanding.","Open the comparison guides",`${o}/product/compare-platforms`)},platformEdgeAiPreview:{navKey:"platform",translationKey:"edgeAiValidationV1",eyebrow:"Edge AI operations",title:"Operate AI workloads across the edge fleet.",lead:"Edge AI operations are undergoing validation. Operate an inference product across Linux devices: manage model versions and delivery, understand service health and connect inference results to the product workflow around them.",seoTitle:"Edge AI Operations for Linux Fleets | Dataplicity",seoDescription:"Edge AI operations are undergoing validation. Manage model delivery, inference health and product workflows across Linux edge devices with Dataplicity.",highlights:["Manage the deployed model as part of the product lifecycle.","Keep model accuracy and application fitness with the team that owns the product.","Use the same fleet operations around AI and non-AI workloads."],sections:[r("why","Operate the AI-powered product, not just the computer running it.","Cost-effective edge compute makes local inference increasingly practical. The operational question is how to deliver, observe and recover that workload across a fleet.",[e("Keep the model and product yours","Dataplicity is not a training or annotation platform. The intended role is operating the model, runtime and resulting product workflow after deployment."),e("Fit it to your workload","Use the model, runtime and accelerator combination appropriate to your product, and keep the detailed integration choices in the technical guide.",`${o}/product/edge-ai-operations`)]),r("evaluate","Prove one workload on the hardware you intend to ship.","Start with the model, runtime and device combination that represents the product you are building.",[e("Deliver and run the model","Verify the supported model reaches the device, loads in the intended runtime and produces the result your application consumes."),e("Observe degradation and recovery","Test restart, lost connectivity and the fallback path you intend to depend on. Keep degraded and unavailable states explicit."),e("Check fleet evidence","Confirm operators can see the active version and service health needed to distinguish a healthy inference product from an online Linux host.",`${o}/product/edge-ai-operations`)]),r("next","Use fleet operations around the workload you already have.","Edge AI is an additional operating path, not a requirement for using Dataplicity around an existing inference application.",[e("Reach and diagnose the device","Use remote access, Pulse and available diagnostic evidence around the workload you run today.","/fleet-operations"),e("Read the integration detail","Runtime, accelerator, model-format and release-specific requirements belong in the technical guidance.",`${o}/product/edge-ai-operations`)])],cta:h("Take one workload from model to operated product.","Use the technical guide for runtime and hardware integration, then connect the workload to the fleet and product workflow around it.","Read the Edge AI technical guide",`${o}/product/edge-ai-operations`)}},v={platformArchitecture:[r("build-or-buy","Decide what to build and what to reuse.","Keep the parts specific to your product. Evaluate the shared services around them as a separate decision.",[e("Dataplicity supplies","Device identity and connectivity, engineering operations, scoped customer access and the application authoring and publishing system. Adopt only the capabilities needed for your product."),e("Your team configures and integrates","Define Device Classes, product data and Commands, customer boundaries, pages, records and workflows. Connect device code to the local agent interface and test the full customer job."),e("Your team retains","Hardware, sensing and calibration, the supported Linux image, physical control and safety, commercial terms and the external systems you choose to keep.",`${o}/product/build-or-buy-connected-product-stack`)]),r("lifecycle-boundaries","Follow the same product through changes and outages.","Review the mechanism at each boundary before planning a production integration.",[e("Software and OS changes","Coordinate versioned application software and RAUC image delivery without confusing their recovery mechanisms.","/platform/software-lifecycle"),e("Disconnected operation","Place necessary work locally and define buffering, command expiry and reconnect handling explicitly.","/platform/offline-edge"),e("Compare an existing stack","Evaluate what you keep, what changes and the operational work left to your team.","/comparison")]),r("secondary-capabilities","Running inference at the edge?","Edge AI operations are available as an additional path and are not required for the core operating or customer-application journeys.",[e("Explore Edge AI operations","Manage the model and inference workload alongside the Linux fleet and the product workflow it serves.","/platform/edge-ai")])],customerApplications:[r("customer-jobs","Show the customer a finished job, not a collection of widgets.","Illustrative product evaluation paths. These are demonstrations to build and test, not accounts of customer deployments.",[e("Monitor and control a site","Let an operator select their site, inspect readings and reading age, review attention state and use a permitted control. Show pending, unavailable and failed states instead of treating every click as a completed physical action.",`${o}/product/build-a-level-monitor-product`),e("Complete a scheduling workflow","Define a schedule, publish the selected local data and show the applied state. Test the disconnected controller and verify recovery before promising the workflow to customers.",`${o}/product/build-an-hvac-scheduling-application`),e("Keep the result reviewable","Use customer-scoped re
1cords and execution state to explain what happened. Evaluate the application Workspace and the report or record needed for the job, including incomplete and failed outcomes.",`${o}/product/design-application-workspace`)]),r("operate-the-product","Connect the customer experience to the product lifecycle.","The customer page and the engineering workspace serve different audiences around the same equipment.",[e("Release device software deliberately","Coordinate application versions and OS images through the appropriate release path without exposing engineering controls to the customer.","/platform/software-lifecycle"),e("Explain the offline state","Keep the customer view honest about last-seen time, stale readings, pending settings and unavailable live controls.","/platform/offline-edge"),e("Prove customer separation","Use separate test accounts and sites. Verify that each user can see and operate only the records and equipment intended for them before inviting production users.",`${o}/product/customer-portal`)])],lifecycle:[r("releases-and-connectivity","The product is deployed. Now it has to keep working.","Start with the next operating gap rather than rebuilding the product around a platform.",[e("Release the next software version","Target a bounded cohort and verify application or RAUC-image outcomes before expanding.","/platform/software-lifecycle"),e("Handle an unreliable connection","Design local work, stored data and recovery around the essential customer job.","/platform/offline-edge"),e("Choose what to replace","Compare the parts your existing tools already cover with the responsibilities Dataplicity can take on.","/comparison")])]},k=new Set(["resourceFaq","networkOutagesPlaybook","logAnalyticsPlaybook","customerWarrantyPlaybook",...Object.keys(m),...Object.keys(f),...Object.keys(v)]);function A(i,c){const a={...i,...Object.fromEntries(Object.entries(c??{}).filter(([,n])=>n&&typeof n.title=="string"&&n.title.trim()&&typeof n.lead=="string"&&Array.isArray(n.highlights)&&Array.isArray(n.sections)&&n.sections.length>0&&n.sections.every(l=>l&&Array.isArray(l.items))))};for(const n of k)i[n]&&(a[n]=i[n]);return a}const T=["resourceDeployment","resourceIntegrations","resourceRunbooks","resourceFaq","networkOutagesPlaybook","logAnalyticsPlaybook","customerWarrantyPlaybook"],w={...g,...m,platformRemoteOps:m.platformRemoteOps,moduleLogs:{navKey:"modules",eyebrow:"Module - IoT device logs",title:"Search Linux device and backend logs with fleet context.",lead:"Stream, tail, and search syslog across edge devices and services, then filter by device identity, customer, tag, or cohort before opening remote access.",highlights:["Tail and search syslog from devices, gateways, applications, and backend services.","Keep each log stream tied to device identity, status, and operational history.","Compare error signatures across tags, device classes, firmware versions, and cohorts."],sections:[{id:"log-ingest",title:"Linux device and service log ingestion",subtitle:"Send syslog through the device connection or configured collectors, then search it from the shared operations timeline.",items:[{label:"Syslog",title:"Unified streams",copy:"Device, SaaS, and backend logs land in one view."},{label:"Search",title:"Fast filtering",copy:"Search by device, cohort, or error signature."},{label:"Context",title:"Device metadata",copy:"Logs carry device tags and metadata."}]},{id:"correlation",title:"Operational context",subtitle:"Logs from devices and services stay tied to device identity so ops can act fast.",items:[{label:"Devices",title:"Device context",copy:"Open the device record to review ownership, status, and alerts, then launch remote access."},{label:"Tags",title:"Fleet filters",copy:"Use tags and cohorts to isolate issues and target the right fix."},{label:"Timeline",title:"Recent activity",copy:"Review log history alongside alerts, deploys, and incident notes."}]}]},resourceDeployment:{navKey:"solutions",eyebrow:"Playbook - Deployment",title:"Deployment guide for the first managed device.",lead:"Install the Dataplicity Agent, register the first unit, verify that the device is online in Dataplicity, add class and customer context, then use that management channel for customer application operations.",highlights:["Copy the install c
1ommand into your image, provisioning system, or first device.","Confirm the first device appears with a recent heartbeat.","Apply class, customer, and rollout metadata before scaling.","Use Dataplicity for customer-code logs and commands after the device is online."],sections:[{id:"onboard",title:"Onboard the first unit",subtitle:"Create the management channel and make the device visible before you turn this into a fleet rollout.",background:"surface",items:[{label:"01 - Install",title:"Run the install command locally",copy:"Use the generated command on the device, in the factory image, or in the provisioning workflow.",terminal:{title:"Install",command:"$ curl -fsSL https://install.dataplicity.com/<provisioning_key>.sh | sudo bash",output:`Dataplicity agent installed 2next=waiting for first check-in`,explanation:"This is the local install step that creates the management channel."}},{label:"02 - Optional local check",title:"Confirm the service is running on the device",copy:"If the device has not appeared yet, a single local service check is enough before returning to the provisioning workflow.",terminal:{title:"Local verification",command:"$ sudo systemctl is-active dataplicity",output:"active",explanation:"This is not the case study; it is just a local sanity check that the install started."}}]},{id:"verify",title:"Verify the device in Dataplicity",subtitle:"Once the device checks in, use Dataplicity CLI to confirm identity, heartbeat, and fleet context.",background:"band",grid:"plays",variant:"play",items:[{label:"03 - Inventory",title:"Find the new device",copy:"The first rollout gate is simple: the device exists in Dataplicity and has a recent heartbeat.",terminal:{title:"Find the new unit",command:"$ dataplicity devices list --class <class> --customer <customer> --since 30m",output:`DEVICE STATUS CLASS CUSTOMER LAST CHECK-IN 3<device> online <class> <customer> 2m ago`,explanation:"From this point, Dataplicity can manage and observe the device remotely."}},{label:"04 - Context",title:"Check class, customer, and rollout metadata",copy:"Make sure the unit is in the right operational cohort before using the same command in production.",terminal:{title:"Describe the device",command:"$ dataplicity devices describe <device>",output:`status=online 4class=<class> 5customer=<customer> 6rollout=pilot 7last_heartbeat=2m ago`,explanation:"Metadata makes later logs, alerts, firmware analysis, and support evidence useful."}}]},{id:"unlocked-operations",title:"What deployment unlocks",subtitle:"After the first heartbeat, Dataplicity can help operate customer code on the remote device.",background:"surface",grid:"plays",variant:"play",items:[{label:"05 - App logs",title:"Tail customer application logs",copy:"Use Dataplicity to inspect customer code only after the device is online.",terminal:{title:"Tail app logs",command:"$ dataplicity logs tail <device> --service customer-app --since 15m",output:`10:44 customer-app: config loaded for <class> 810:45 customer-app: ready`,explanation:"This validates customer application observability through the management channel."}},{label:"06 - Remote command",title:"Check a customer service remotely",copy:"Run targeted commands against customer services once the management channel is present.",terminal:{title:"Inspect customer service",command:"$ dataplicity run <device> -- systemctl status customer-app --no-pager",output:`customer-app.service active (running) 9exit=0`,explanation:"This is the operational handoff: deployed devices can now be managed without a truck roll."}}]},{id:"conclusion",title:"Deployment gate",subtitle:"A device is ready for rollout when Dataplicity can identify it, monitor it, and operate customer code.",background:"surface",items:[{label:"Gate",title:"Require heartbeat and metadata",copy:"The first successful check-in should carry class, customer, and rollout context before the process scales."},{label:"Alerting",title:"Add a heartbeat rule for the class",copy:"On-call should know when the new cohort stops checking in."},{label:"Operations",title:"Move to customer-code playbooks",copy:"Use the case-study playbooks for logs, firmware cohorts, network evidence, runbooks, and warranty support once devices are online."}]}],cta:{title:"Deploy the first managed device.",copy:"Install the agent to get the first unit online. For agent options, device APIs, and day-two operations, open the documentation.",primaryLabel:"Get install c
9ommand",primaryTo:"/login",secondaryLabel:"Open documentation",secondaryTo:"https://docs.dataplicity.com"}},resourceIntegrations:m.resourceIntegrations,resourceRunbooks:{navKey:"solutions",eyebrow:"Playbook - Runbooks",title:"Decide whether a field failure needs a site visit.",lead:"A customer reports devices failing at a remote site. For devices that are online in Dataplicity, use alerts, logs, customer, warranty, and remote-access evidence to build a repeatable runbook before sending a technician.",highlights:["Start from an incident or affected cohort.","Collect logs, status, and remote command output from online devices.","Attach findings to the incident timeline.","Preserve an audit trail for support and warranty decisions."],sections:[{id:"scenario",title:"The support scenario",subtitle:"A remote-site escalation needs a repeatable path from alert to evidence to action.",background:"surface",items:[{label:"Signal",title:"The customer reports field impact",copy:"You have an incident, a customer name, and maybe one device, but not the full affected cohort or likely cause."},{label:"Risk",title:"Every responder debugs differently",copy:"Without a runbook, teams rerun different checks and lose the evidence needed for customer follow-up."},{label:"Goal",title:"Build a CLI-backed response path",copy:"Collect status, logs, remote diagnostics, and incident notes in a consistent order once the device is online in Dataplicity."}]},{id:"cli-investigation",title:"CLI runbook walkthrough",subtitle:"Use one flow for triage, diagnosis, action, and evidence capture.",background:"band",grid:"plays",variant:"play",visual:"automation",items:[{label:"01 - Triage",title:"Start from the open incident",copy:"The incident gives alert source, affected customer, and current responder ownership.",terminal:{title:"Inspect incident",command:"$ dataplicity incidents show <incident> --include alerts,devices,customer",output:`severity=critical 10customer=<customer> 11affected_devices=18 12primary_alert=heartbeat_missing`,explanation:"The runbook starts with the scope Dataplicity already knows."}},{label:"02 - Cohort",title:"List affected devices and context",copy:"Group by class, customer, network, or tag before deciding what failed.",terminal:{title:"Scope impact",command:"$ dataplicity devices list --incident <incident> --group-by class,network,status",output:`CLASS NETWORK OFFLINE ONLINE 13<class> <network> 18 42 14<class> backup-lte 0 37`,explanation:"The operator can see whether the issue is isolated to a network cohort or customer site."}},{label:"03 - Evidence",title:"Collect logs and a safe remote check",copy:"Attach output to the incident so the next responder does not need to rerun it.",terminal:{title:"Capture evidence",command:'$ dataplicity logs query --incident <incident> "error OR timeout" --last 30m --save-evidence',output:`saved_evidence=<evidence> 15matches=64 16top_signature="modem: registration denied"`,explanation:"The incident now has a searchable evidence bundle tied to device identity."}}]},{id:"conclusion",title:"Operational conclusion",subtitle:"Turn a one-off fix into a reusable response path.",background:"surface",items:[{label:"Document",title:"Attach the command sequence to the incident",copy:"The exact checks become a runbook for the next responder and an audit trail for the customer."},{label:"Automate",title:"Promote safe checks into scheduled tasks",copy:"Recurring health checks can run against the same cohort before customers notice the next issue."},{label:"Communicate",title:"Publish only customer-safe facts",copy:"Status pages can share the conclusion while internal diagnostics stay private."}]}],cta:{title:"Connect runbooks to live device evidence.",copy:"Make every incident response repeatable from alerts through logs, remote checks, and customer updates.",primaryLabel:"Get install command",primaryTo:"/login",secondaryLabel:"Back to playbooks",secondaryTo:"/solutions"}},resourceFaq:{navKey:"solutions",eyebrow:"Playbook - FAQ",title:"OEM engineer FAQ for CLI-led operations.",lead:"Short, concrete answers about using Dataplicity as the operational layer for deployed devices â from first install through day-two support.",highlights:["What Dataplicity adds beyond a runtime.","How provisioning, logs, and remote access tie to one device record.","What data is collected and how access is governed.","Which playbooks to run first with a real device."],sections:[{id:"faq-core",title:"Platform fit",subtitle:"How Dataplicity sits alongside Greengrass, balena, systemd, containers, or your own supervisor.",background:"surface",items:[{title:"Does Dataplicity replace our runtime?",copy:"No. Keep your existing runtime and application stack. Dataplicity provides the operational layer: inventory, logs, alerts, incidents, remote access, customer context, and audit history tied to each device record."},{title:"Which stacks does it work with?",copy:"Any Linux device that can run the agent and reach the internet. Most teams pair Dataplicity with Greengrass, balena, systemd services, Docker, or custom supervisors â the agent adds fleet identity and ops without replacing how you ship software."},{title:"What does the CLI give us that a dashboard does not?",copy:"The CLI lets on-call move from an alert to the exact device, customer, class, logs, event history, and remote diagnostic command in one flow â without clicking through separate tools.",terminal:{title:"Start from a device",command:"$ dataplicity devices show <device> --include customer,warranty,alerts,events",output:`customer=<customer> 17warranty=active 18open_alerts=1 19last_event=first_heartbeat 12m ago`,explanation:"Operational context, not just connectivity."}},{title:"What data does Dataplicity collect?",copy:"Device identity, status, heartbeats, logs, events, and operator actions you configure â all tied to customer, class, warranty, and incident context. You control what is forwarded from customer applications and backend services."}]}
19,{id:"faq-deployment",title:"Deployment and provisioning",subtitle:"From the first pilot device to repeatable factory or field rollout.",background:"band",items:[{title:"How do we onboard the first device?",copy:"Run the install command on a device, confirm it appears in inventory with a recent heartbeat, then attach class and customer metadata before scaling the same process to production cohorts.",terminal:{title:"Verify the first check-in",command:"$ dataplicity devices list --class <class> --customer <customer> --since 30m",output:`DEVICE STATUS CLASS CUSTOMER LAST CHECK-IN 20<device> online <class> <customer> 2m ago`,explanation:"The deployment gate is a live device record with context, not just a successful curl."}},{title:"Can we embed the agent in factory images?",copy:"Yes. Bake the install command or provisioning key into image build, Mender, balena fleet deploy, or your own first-boot script. Device classes carry per-SKU defaults so each product line gets the right tags and collectors automatically."},{title:"How do device classes and customer context propagate?",copy:"Classes define provisioning defaults, log collectors, and alert templates. Customer and site metadata attach to each device record so support, warranty, and status pages can scope evidence correctly from day one."}]},{id:"faq-operations",title:"Day-two operations",subtitle:"Logs, remote access, and fleet-wide patterns after devices are in the field.",background:"surface",items:[{title:"How does remote access work without VPN or inbound ports?",copy:"The agent opens an outbound connection to Dataplicity. Support opens a secure shell or forwarded port from the browser â no inbound port or customer VPN is needed. The device must be able to reach Dataplicity under the customerâs outbound network policy."},{title:"How do logs tie back to device identity?",copy:"Collectors and ingest paths attach logs to class, customer, and device records. Search and tail operations scope by cohort instead of dumping IoT syslog into a server-centric log platform.",terminal:{title:"Search integrated logs",command:'$ dataplicity logs query --class <class> --customer <customer> "retry timeout" --last 1h',output:`12 matches 21<device> edge-api retry timeout after deploy <version>`,explanation:"Investigations start from product context, not raw text search."}},{title:"What if many devices go offline at once?",copy:"Group by network tag, region, or customer before dispatching technicians. Heartbeat alerts plus cohort filters help distinguish provider outages from isolated hardware faults â see the network outages playbook for a worked example."}]},{id:"faq-security",title:"Security and access",subtitle:"Remote access and evidence should be governed from the same platform.",details:["SSO, MFA, roles, and group scopes govern org access.","Session opens, file transfers, and device actions are auditable.","Customer-facing pages can publish safe facts without exposing internal diagnostics."],background:"band",variant:"play",items:[{title:"Do you support SSO, MFA, and SCIM?",copy:"Yes. SAML SSO, MFA enforcement, and SCIM provisioning are built into org settings so fleet access follows the same policies as the rest of your tooling."},{title:"Can we restrict CLI and terminal access?",copy:"Yes. CLI and terminal actions are governed by org roles and group scopes, so responders get the access they need without sharing VPN credentials or SSH keys."},{title:"Is there an audit trail?",copy:"Yes. Security activity, remote-access and device-action records, incident notes, and event history provide evidence for support, warranty, and compliance review. Sessions are recorded as access events rather than keystroke transcripts.",terminal:{title:"Review access history",command:"$ dataplicity security activity --device <device> --last 24h",output:`10:41 login <operator> 2210:44 remote_access.terminal_opened <device> 2310:47 incident.note <incident>`,explanation:"The same system that fixes the device also records who acted and why."}},{title:"Can customers see status without internal access?",copy:"Yes. Status pages and read-only dashboards publish uptime and incident updates from live monitors â customers get transparency without credentials to your internal ops tools."}]},{id:"faq-start",title:"Getting started",subtitle:"A practical path from evaluation to repeatable operations.",background:"surface",items:[{title:"Where should we start?",copy:"Install one real device, confirm inventory and metadata, then tail customer-app logs and open a remote session. That validates the management channel before you scale provisioning."},{title:"Which playbooks should we read next?",copy:"Use the deployment guide for first-device rollout, the integration guide to wire app logs into the device model, the incident runbooks for on-call response, and the case-study playbooks for network outages, log analytics, and customer warranty workflows."}]}],cta:{title:"Try the CLI flow with a real device.",copy:"Start with an install c
23ommand, then validate inventory, logs, alerts, and remote access from one device record.",primaryLabel:"Get install command",primaryTo:"/login",secondaryLabel:"Back to playbooks",secondaryTo:"/solutions"}},networkOutagesPlaybook:{navKey:"solutions",eyebrow:"Playbook case study - Network outages",title:"Investigate a fleet that goes offline together.",lead:"Worked scenario: several gateways stop checking in together. Use device inventory, alerts and collected logs to narrow the cause and decide what to check before sending a technician.",highlights:["Scope outage by network cohort, customer, and region.","Compare offline devices with backup connectivity cohorts.","Use logs and events to separate provider issues from device faults.","Attach evidence before updating customers."],sections:[{id:"scenario",title:"What the operator knows",subtitle:"A heartbeat alert fired for multiple devices at the same time.",background:"surface",items:[{label:"Signal",title:"Many devices missed heartbeats together",copy:"That pattern is unlikely to be dozens of independent hardware failures."},{label:"Context",title:"The affected units share a connectivity tag",copy:"The fleet has tags like connectivity:starlink, region, customer, and device class."},{label:"Decision",title:"Support must decide whether to dispatch",copy:"The answer depends on whether evidence points to field hardware or provider state."}]},{id:"cli-investigation",title:"CLI investigation walkthrough",subtitle:"Start from the alert, scope the cohort, then collect customer-safe evidence.",background:"band",grid:"plays",variant:"play",visual:"ops",items:[{label:"01 - Alert",title:"Inspect the outage alert",copy:"The alert gives the first affected cohort and incident link.",terminal:{title:"Open alert context",command:"$ dataplicity alerts show <alert> --include incident,cohort,devices",output:`incident=<incident> 24cohort=connectivity:starlink 25affected_devices=31 26first_seen=09:12`,explanation:"The investigation starts with a fleet pattern, not a single device guess."}},{label:"02 - Scope",title:"Compare network cohorts",copy:"If backup LTE devices stayed online, the evidence points away from the application or device class.",terminal:{title:"Group by network",command:"$ dataplicity devices list --customer <customer> --group-by network,status",output:`NETWORK OFFLINE ONLINE 27connectivity:starlink 31 4 28connectivity:lte 0 29 29lan 0 12`,explanation:"The outage is isolated to one connectivity cohort, so dispatching hardware technicians is premature."}},{label:"03 - Logs",title:"Look for last-known network errors",copy:"Last-known logs show whether devices saw modem, DNS, or route failures before they went offline.",terminal:{title:"Search cohort logs",command:'$ dataplicity logs query --tag connectivity:starlink "modem OR route OR dns" --last 2h',output:`31 devices matched 3009:11 <device> modem: link lost 3109:11 <device> route: default gateway unreachable`,explanation:"This uses stored log evidence from before the outage; live remote commands require the device to be online in Dataplicity."}}]},{id:"conclusion",title:"Operational conclusion",subtitle:"Dataplicity turns a noisy offline event into a specific next move.",background:"surface",items:[{label:"Do not dispatch",title:"Hold field visits until provider status is confirmed",copy:"The CLI evidence shows this is a shared network cohort issue, not isolated device failure."},{label:"Escalate",title:"Send provider escalation with affected count",copy:"The incident contains device count, customer, region, and log signatures."},{label:"Communicate",title:"Publish a customer-safe status note",copy:"Status pages can say connectivity provider degradation while internal logs remain private."}]}],cta:{title:"Diagnose network cohorts, not individual devices.",copy:"Use Dataplicity to connect alerts, logs, device tags, incidents, and customer updates.",primaryLabel:"Get install command",primaryTo:"/login",secondaryLabel:"Back to playbooks",secondaryTo:"/solutions"}},logAnalyticsPlaybook:{navKey:"solutions",eyebrow:"Playbook case study - Firmware log analytics",title:"Investigate errors after a pilot software release.",lead:"Worked sce
31nario: a small group starts reporting sensor timeouts after a new build. Compare collected errors with devices on the previous version, then use diagnostics on online devices to investigate.",highlights:["Find the error signature across device logs.","Correlate matches with version, class, and rollout cohort.","Use remote checks only on devices that are online in Dataplicity.","Hold or roll back the rollout with evidence attached."],sections:[{id:"scenario",title:"What the operator knows",subtitle:"The support queue has several reports, but nobody knows whether the issue is widespread.",background:"surface",items:[{label:"Signal",title:"Support keeps seeing the same timeout",copy:"The phrase is visible in tickets, but tickets do not reveal the affected cohort or firmware version."},{label:"Context",title:"The issue may align with a rollout",copy:"Dataplicity keeps version, class, tags, events, and logs tied to the same device record."},{label:"Decision",title:"Engineering must decide whether to pause",copy:"The decision needs evidence, not anecdotes."}]},{id:"cli-investigation",title:"CLI investigation walkthrough",subtitle:"Query the signature, correlate affected devices, then preserve the evidence.",background:"band",grid:"plays",variant:"play",visual:"firmware",items:[{label:"01 - Signature",title:"Search logs for the repeated error",copy:"Start with the phrase support saw and let Dataplicity return device-aware matches.",terminal:{title:"Find matching logs",command:'$ dataplicity logs query "sensor read timeout" --last 6h --group-by device',output:`devices=42 32matches=389 33top_device=<device> 34first_seen=14:08`,explanation:"The issue is broader than one support ticket and has a clear first-seen time."}},{label:"02 - Correlate",title:"Group matches by version and class",copy:"Logs know product context, not just text.",terminal:{title:"Summarize by context",command:'$ dataplicity logs query "sensor read timeout" --last 6h --group-by firmware,class,rollout',output:`FIRMWARE CLASS ROLLOUT DEVICES 35<version> <class> pilot-west 42 36previous <class> stable 0`,explanation:"The failure maps to the pilot rollout rather than the whole fleet."}},{label:"03 - Evidence",title:"Attach analysis to a rollout incident",copy:"Engineering and support need the same proof when deciding to pause or roll back.",terminal:{title:"Save investigation",command:'$ dataplicity incidents create --title "Pilot rollout sensor timeout" --from-query <query>',output:`incident=<incident> 37evidence=log-query,affected-devices,version-summary 38status=open`,explanation:"The incident carries the affected version, devices, and log proof for the rollback decision."}}]},{id:"conclusion",title:"Operational conclusion",subtitle:"Move from log search to rollout control and customer messaging.",background:"surface",items:[{label:"Pause",title:"Hold the pilot rollout",copy:"The affected cohort is known, so engineering can stop expansion without guessing."},{label:"Target",title:"Create a rollback cohort",copy:"Use class, version, and rollout tags to target exactly the affected units."},{label:"Inform",title:"Share impact with support",copy:"Support sees the same device list, incident notes, and customer-safe summary."}]}],cta:{title:"Turn logs into product decisions.",copy:"Use Dataplicity to correlate errors with device class, version, rollout, incidents, and remote diagnostics.",primaryLabel:"Get install command",primaryTo:"/login",secondaryLabel:"Back to playbooks",secondaryTo:"/solutions"}},customerWarrantyPlaybook:{navKey:"solutions",eyebrow:"Playbook case study - Customer status + warranty",title:"Gather device evidence before approving a replacement.",lead:"Worked scenario: a customer reports a failed unit and asks for a replacement. Review coverage, device history and collected logs. Use live diagnostics when the device is online, then decide whether a remote fix, visit or return is needed.",highlights:["Start from customer and device identity.","Check warranty and entitlement context.","Collect logs and remote diagnostics before dispatch.","Turn evidence into customer-safe status and service history."],sections:[{id:"scenario",title:"What support knows",subtitle:"A customer reports an outage, but the team needs evidence before shipping replacement hardware.",background:"surface",items:[{label:"Signal",title:"Customer says the device failed",copy:"The report arrives before support knows whether the device is offline, misconfigured, or out of warranty."},{label:"Context",title:"Warranty and customer data matter",copy:"Dataplicity keeps customer, warranty, device class, and service history beside operational evidence."}
38,{label:"Decision",title:"Approve dispatch only with proof",copy:"Support needs enough evidence to choose RMA, remote fix, or customer guidance."}]},{id:"cli-investigation",title:"CLI investigation walkthrough",subtitle:"Move from customer report to service decision without copying data between tools.",background:"band",grid:"plays",variant:"play",visual:"status",items:[{label:"01 - Customer",title:"Find warranty context",copy:"Start from customer identity, not a loose serial number in a ticket.",terminal:{title:"Open customer context",command:"$ dataplicity customers show <customer> --include devices,warranty,open-incidents",output:`devices=128 39open_incidents=1 40warranty.active=117 41warranty.expiring_30d=9`,explanation:"Support can immediately see covered devices and active incidents."}},{label:"02 - Device",title:"Inspect the affected unit",copy:"The device record links status, warranty, firmware, class, and recent alerts.",terminal:{title:"Check device state",command:"$ dataplicity devices show <device> --include customer,warranty,status,alerts",output:`customer=<customer> 42warranty=active 43status=online 44alert=storage_pressure 45last_check_in=1m ago`,explanation:"The unit is online and covered, so remote diagnostics are worth trying before dispatch."}},{label:"03 - Diagnostics",title:"Collect proof before replacement",copy:"Logs and read-only commands show whether this is hardware, storage pressure, or application failure.",terminal:{title:"Remote diagnostic",command:'$ dataplicity terminal exec <device> -- "df -h /var && journalctl -u edge-app -n 20"',output:`/var 96% used 46edge-app: cache pruning skipped 47exit=0`,explanation:"Support can recommend remote remediation and attach proof to service history."}}]},{id:"conclusion",title:"Operational conclusion",subtitle:"The conclusion becomes service history, customer communication, and warranty evidence.",background:"surface",items:[{label:"Remote fix",title:"Run or schedule a cleanup task",copy:"The device is online and the fault is software or storage related, so support can remediate before dispatch."},{label:"Warranty",title:"Keep evidence if replacement is still needed",copy:"If the issue returns, logs and diagnostics are already attached to the customer and device record."},{label:"Customer trust",title:"Publish a customer-safe update",copy:"Status and support notes can say investigation complete and remediation in progress without exposing internal logs."}]}],cta:{title:"Make warranty decisions from live evidence.",copy:"Connect customer context, device health, logs, incidents, warranty, and remote diagnostics in one support flow.",primaryLabel:"Get install command",primaryTo:"/login",secondaryLabel:"Back to playbooks",secondaryTo:"/solutions"}}},x={...w,...f};for(const[i,c]of Object.entries(v)){const a=w[i];if(!a)throw new Error(`Unknown buyer journey: ${i}`);const n=new Set(a.sections.map(p=>p.id));for(const p of c){if(n.has(p.id))throw new Error(`Duplicate marketing section: ${i}/${p.id}`);n.add(p.id)}const l=a.sections.findIndex(p=>p.id==="plans"),u=l<0?a.sections.length:l;x[i]={...a,sections:[...a.sections.slice(0,u),...c,...a.sections.slice(u)]}}export{S as B,x as F,T as P,A as m};
Line numbers count LF bytes from the start of the resource, as the search results do. Vendor segments are library code the classifier recognised; they are stored but not indexed. Bytes are shown as Latin1 characters, one per byte.