- Detect non-TTY environments when running with --in-container
- Automatically select appropriate update based on configured channel
- Prevents hanging on menu prompt in ProxmoxVE deployments
- Users now see both stable and RC versions when updating
- Menu dynamically adjusts based on available versions
- Users can choose which version to install regardless of their update channel setting
- Addresses confusion about automatic RC updates
Previous fix wasn't working properly - the menu showed but couldn't read input.
Now properly detects if we can write to /dev/tty to determine if interaction
is possible, even when stdin is piped from curl.
The script was detecting piped input and automatically going into non-interactive mode,
preventing users from choosing between Quick and Advanced installation modes.
Now checks if /dev/tty is available even when stdin is piped, allowing interaction
through the terminal for curl-based installations while still supporting truly
non-interactive environments (like automation scripts without any TTY).
- Add safe_read function to handle both TTY and non-TTY input
- Fix --in-container mode to skip prompts when no TTY available
- Allows installation via piped curl command on Proxmox hosts
- Install script now prompts for custom port (default: 7655)
- Can skip prompt with FRONTEND_PORT environment variable
- Fixed incorrect port configuration instructions in UI
- Updated documentation to reflect new installation options
- Fixed FAQ.md references to pulse-backend (should be pulse)
addresses #110
- Added comprehensive PORT_CONFIGURATION.md guide
- Updated CONFIGURATION.md to clarify .env is for auth only
- Install script no longer loads .env for environment variables
- Documented proper port configuration methods (systemd, system.json)
- Added port config guide to README documentation section
addresses #110 - helps users understand where to configure ports
- Auto-detects Proxmox VE hosts and creates LXC containers
- Quick mode with sensible defaults (1GB RAM, 4GB disk)
- Advanced mode for full customization
- Automatic cleanup on failure
- Simple 'update' command in containers
- Improved error handling and network detection
- Professional, clean output without verbose noise
- Docker detection to prevent container-in-container
- Removed all references to community scripts
This is now the primary recommended installation method.
Users now have two options when creating the LXC container:
1. Quick mode - Uses optimized defaults for production (2GB RAM, 16GB disk, etc)
2. Advanced mode - Full control over all settings like the community script
Advanced mode allows customization of:
- Memory, CPU cores, CPU limits, swap
- Static IP vs DHCP
- DNS servers
- Firewall settings
- Privileged vs unprivileged
- Auto-start on boot
- Startup order
This gives users the best of both worlds - quick setup with good defaults
or full control when needed.
- Increased default RAM to 2GB (handles 50+ nodes)
- Increased default disk to 16GB (logs and metrics storage)
- Added CPU limit to prevent resource hogging
- Added 512MB swap for memory flexibility
- Enabled firewall on network interface
- Set startup order to 99 (after critical services)
- Configure UTC timezone for consistent logging
- Optimize sysctl settings for monitoring workload
- Added clear documentation of optimizations applied
The installer now detects when running on a Proxmox VE host and automatically:
- Creates a new LXC container with user-specified settings
- Installs Pulse inside the container
- Prevents unsafe installation directly on PVE hosts
This eliminates dependency on community scripts while ensuring proper isolation.
The installer was installing Go and Node.js even for binary installations.
Now it only installs curl and wget which are needed to download the release.
Move service stop to happen before attempting to copy the binary file.
This prevents the error when the binary is still in use by the running service.
Added 2-second delay to ensure process fully releases the file.
- ProxmoxVE community script uses pulse-backend.service
- Our install script now detects and preserves existing service name
- Removed pulse-backend.service from pre-v4 detection (it's used by v4 too)
- Install script stops the correct service during upgrades
- New installs use 'pulse', existing use whatever they have
This ensures compatibility with all deployment methods without breaking changes.
The service name pulse-backend.service is used by both v4 and pre-v4 installations,
so it's not a reliable indicator. Only check for Node.js artifacts (package.json,
node_modules, etc) which are exclusive to pre-v4 versions.
The install script now accepts arguments that work with piped execution:
- --rc or --pre: Install latest RC/pre-release
- --stable: Force stable version (default)
- --version VERSION: Install specific version
- --help: Show usage
This allows users to update to RC versions with:
curl -fsSL .../install.sh | bash -s -- --rc
- Check system.json for configured update channel
- Fetch pre-releases when RC channel is configured
- Support PULSE_UPDATE_CHANNEL env var to force RC updates
- Users can now update to RC versions with:
PULSE_UPDATE_CHANNEL=rc curl -fsSL ... | bash
Emergency release to fix critical issues in v4.3.7:
- Install script now correctly installs binary to /opt/pulse/bin/pulse
- Password changes no longer require sudo (addresses #317)
These fixes restore basic functionality for new installations
and Docker deployments.
- ALL archives now use bin/pulse structure (including architecture-specific)
- Matches what Proxmox community script expects
- Install script checks bin/ first, falls back to root for old archives
- Eliminates confusion from having two different structures
- One consistent path forward: archives have bin/ directory
- Current dual-path logic needed for backwards compatibility
- v4.3.0 universal archive has bin/ structure
- Architecture-specific archives have pulse in root
- TODO: Standardize on single structure in v5
- Install script now handles both archive layouts (with/without bin directory)
- Service file points to correct path: /opt/pulse/pulse (not /opt/pulse/bin/pulse)
- Fixes service startup issue in fresh LXC installations
Addresses #304 - Eliminates redirect loops and path issues by embedding
the frontend directly in the Go binary using go:embed
- Frontend is now embedded at compile time, no separate files needed
- Simplified tarball structure - just the binary and config files
- No more path searching or frontend directory issues
- Works consistently across all installation methods
- Smaller deployment footprint and simpler installation
This change makes Pulse a true single-binary deployment, eliminating
the complexity of managing separate frontend files and the issues that
arose from different installation structures.
- Fixed hardcoded version fallback showing 4.1.1 instead of current version
- Fixed install script syntax error that prevented fresh installations
- Identified root cause of Docker persistence issue (notification UI not saving)
- Identified missing save functionality in frontend notification settings
Issues addressed: #277, #278, #282
- Modified build-release.sh to create tarballs with bin/ directory structure
- Updated install.sh to handle both old (flat) and new (bin/) structures
- Files now extract to correct locations for community scripts
- Fixes issue #276 where community scripts couldn't update properly
Replaced sudo-based updater with a cleaner directory-based approach:
- Pulse binary now installs to /opt/pulse/bin/pulse (owned by pulse user)
- Symlink created at /usr/local/bin/pulse for PATH convenience
- Pulse user has full write access to /opt/pulse, enabling self-updates
- Removed sudo dependency and security risks
- Simplified update logic - no special scripts or permissions needed
This is more secure, simpler, and works in all environments (containers, VMs, bare metal)
- Created pulse-updater script that runs with sudo to update root-owned binary
- Modified install.sh to set up sudoers permissions for pulse user
- Updated build-release.sh to include scripts directory in releases
- Install script now installs sudo (if missing) and configures NOPASSWD access
This fixes the 'Failed to apply update' error when Pulse runs as non-root user
and needs to update the binary at /usr/local/bin/pulse
- Frontend-modern directory is now copied to /usr/local/bin during installation
- Fixes ERR_TOO_MANY_REDIRECTS issue (#268)
- Ensures UI is accessible after binary installation
- Download architecture-specific releases (amd64, arm64, armv7)
- Install binary to /usr/local/bin/pulse (standard location)
- Stop service during updates to prevent file-in-use errors
- Fix systemd service to use correct binary path
- Properly extract and install VERSION file
- Fix utils.GetDataDir() to default to /etc/pulse instead of /var/lib/pulse
- Add explicit PULSE_DATA_DIR=/etc/pulse to systemd service
- This fixes issue #254 where alerts were trying to use wrong directory
- Ensures consistency: Docker uses /data, manual installs use /etc/pulse
- Single directory for all data (config + runtime)
- Docker uses /data (via PULSE_DATA_DIR env var)
- Manual installs use /etc/pulse (default)
- Removed unnecessary /var/lib/pulse directory creation
- Updated docs to clarify data storage locations
This eliminates confusion about multiple directories and follows
the principle of keeping things simple.
- Detect Node.js based installations (any version before v4)
- Block auto-update with migration required message
- Add detailed migration instructions to install.sh
- Check for .env, node_modules, old services, etc.
- Direct users to create fresh installation for v4
- Add comprehensive install.sh script for LXC and manual installations
- Add systemd service file (pulse.service)
- Add build-release.sh for creating release archives
- Support for multiple architectures (amd64, arm64, armv7)
- Automatic dependency installation (Go, Node.js)
- User creation and permission management
- Update/reinstall/remove functionality
- Matches the installation experience of the original Pulse
Pulse Monitor