Skip to content
JelinaJelina DocumentationTechnical documentation
Back to website

Production workflow

This page describes a project workflow for managing edge devices with JelinaCloud. The installed components are the device operating system and business applications; JelinaCloud provides onboarding, application delivery, monitoring, control, and remote maintenance.

  • Architecture and computing capacity: Select ARM64 or x86_64 based on business programs, container images, and AI runtimes. Verify that CPUs, accelerators, and application architectures match.
  • Memory and storage: Reserve space based on service count, log volume, write frequency, and update package sizes. Verify that the storage medium suits site conditions.
  • Peripherals and drivers: Verify serial, CAN, Ethernet, camera, and other interfaces, along with drivers, kernel, and device support packages.
  • Power and environment: Choose devices based on site power, temperature, vibration, and networking, then validate actual operation.

Check JelinaOS supported devices before finalizing the hardware and system combination.

  1. Choose a JelinaOS image matching the device type. Verify compatibility requirements for the distribution, system purpose, kernel, and Jelinvisor version.
  2. Determine whether applications run as containers or native programs. List libraries, runtimes, device permissions, and startup parameters. To capture a native runtime environment, first validate incremental package configuration on a test device.
  3. Ensure devices can reach the project’s JelinaCloud service and application download URLs. Configure networking, time synchronization, and remote access according to site requirements.
  4. Separate applications, configuration, and persistent data. Determine which data must survive service recreation, system updates, and device recovery.
  1. Prepare organizations, teams, fleets, and management permissions, defining each member’s resource responsibilities.
  2. Follow device onboarding to download images and configuration, then flash according to device-specific installation instructions.
  3. Boot and connect the device. Confirm that it appears in the target fleet and verify device type, system information, online status, and logs.

Registration configuration contains credentials. Store and use it separately for each device; do not distribute it as a public example.

Stage 3: Build and validate an application release

Section titled “Stage 3: Build and validate an application release”
  1. Create a Release containing container images, native programs, and required service configuration.
  2. Deploy it to test devices and configure service variables and runtime dependencies.
  3. Verify that current and target Releases match, services run normally, and logs show no errors. Validate business functionality, resource usage, and persistent data.
  4. Test behavior after network reconnection, service restarts, and device restarts to understand cloud and on-site dependencies.

Run a pilot in a test fleet or a group of validation devices before expanding according to the project plan. Manage test and production devices in separate fleets, checking target versions, service variables, and update policies independently.

  • Use fleet version selection to control the target Release. Check whether Latest makes the fleet follow the newest version automatically.
  • Check individual devices for pinned versions that may differ from fleet policy.
  • Record versions and validation results before and after release. Confirm actual update status for offline devices after reconnection.
  • Prepare an incident response plan. Validate data and configuration compatibility when switching application versions. Follow the compatibility and upgrade rules for system, kernel, and agent updates.

Stage 5: Continuous monitoring and maintenance

Section titled “Stage 5: Continuous monitoring and maintenance”

Check online status, services, resources, and logs as needed. Use remote access for diagnostics within your permissions. Validate fixes on test devices before delivery to target fleets.

When transferring, decommissioning, or removing devices from a project, also review cloud device records, fleet membership, remote access permissions, and on-device business data. See device control for available actions and their scope.

Stage Results to confirm
Design Hardware/system compatibility, application runtime, network requirements, and data retention
Device onboarding Test devices belong to the correct fleet, with accessible status and logs
Release validation Releases, variables, and runtime verified; business and recovery tests recorded
Release Update scope, target versions, maintenance windows, and incident plans defined
Ongoing operations Traceable status, clear responsibilities and permissions, and repeatable validation for future updates