nginx-1.31.4 mainline version has been released.
nginx-1.31.4 mainline version has been released.
nginx-1.31.4 mainline version has been released.
This is the first release candidate for Coolify v4.4. It is intended for testing and validation before the stable v4.4 release.
Do not use this release candidate in production without appropriate testing. Please report regressions through GitHub Issues.
nextThese notes include only changes currently unique to next compared with main.
Comparison: main...next
Full Changelog: v4.3.8...v4.3.9
General
API
Media-Over-QUIC
RTSP
RTMP
inform about authentication failures (#5657) (#6072) Reply with NetStream.Play.Failed or NetStream.Publish.Unauthorized when a client is not authorized to play or publish. This makes clients like OBS to stop recreating the connection in case of authentication failures.
reader: do not emit empty frames (bluenviron/gortmplib#106)
parse video PTS delta as signed (bluenviron/gortmplib#88)
HLS
prefer hls.js on iOS too (#6090) In the embedded HLS reader, use hls.js on iOS, that was previously disabled due to compatibility issues that should have been solved.
unlock the session-in-query+iOS combination (#6088) this was previously blocked because the session in query was meant to be dynamic, therefore incompatible with static playlists required by iOS. It is not anymore, so we can support that.
stop using cookies with plain HTTP (#6089) in case of plain HTTP, fall back to query parameters, which are safer than HTTP cookies because they are not shared between different pages/domains, although they are visible in the URL.
WebRTC
SRT
RPI Camera
Dependencies
Binaries are compiled from source code by the Release workflow, which is a fully-visible process that prevents any change or external interference in produced artifacts.
Checksums of binaries are also published in a public blockchain by using GitHub Attestations, and they can be verified by running:
ls mediamtx_* | xargs -L1 gh attestation verify --repo bluenviron/mediamtx
You can verify checksums of binaries by downloading checksums.sha256 and running:
cat checksums.sha256 | grep "$(ls mediamtx_*)" | sha256sum --check
Full Changelog: v4.3.7...v4.3.8
If you are upgrading from v0.16.x, replace the binary (or run docker pull). If you are upgrading from v0.15.x and below, please read the upgrading documentation for more information on how to upgrade from previous versions.
inboundReportMaxSize setting, which bounds the size of a decompressed inbound DMARC or TLS report (default 25MB).cacheSize setting, which bounds the total memory shared by the block caches of every column family (default 128MB).Identity/get keeps identities in sync with the account's e-mail addresses.uploadTtl to 1ms triggers panic.CalendarEvent/set does not assign organizerCalendarAddress nor send scheduling messages when an event is created with participants.CalendarEvent/get omits isOrigin when it is listed explicitly in properties.CalendarEventNotification/changes and FileNode/changes reject with cannotCalculateChanges the state that /get returned for an account with no change history.CalendarEvent/set and ContactCard/set do not write a vanished tombstone for the previous CalDAV/CardDAV href when calendarIds or addressBookIds moves an item between collections.mailto: URI are queued verbatim.REPORTs and JMAP CalendarEvent/query results a few years after their first occurrence.MOVE on a folder honors a Depth header of 0 or 1 instead of always moving the whole subtree.Message-ID wrapped in doubled angle brackets.source never match at enqueue.testing mode are enforced, turning any TLS error into a permanent failure.mx patterns published as U-labels never authorize the MX host they name.application/octet-stream as Content-Type for encrypted payloads.550 Relay not allowed, unless the domain's primary name happened to be resolved earlier and is still cached.bufferSize setting was applied to the unused default column family and had no effect.include statements fail to find system and user global scripts whose name contains uppercase characters.totalDeadline is measured from the time a task was created instead of its first failed attempt.
coolify.managed=true label (#8831, closes #8822).Full Changelog: v4.3.6...v4.3.7
Full Changelog: v4.3.5...v4.3.6
Full Changelog: v4.3.4...v4.3.5
Full Changelog: v4.3.3...v4.3.4
Full Changelog: v4.3.2...v4.3.3
New uNmINeD development snapshot is available for download!
Changes:
--textures=true) experimental feature is no longer availableuNmINeD now can read and use 3D block models from Java Edition client JARs and datapacks, and render them in 2.5D top-down and isometric views.
Bedrock Edition does not have 3D block models available for external tools, so uNmINeD uses Java block models to render Bedrock blocks. You will need a Java client JAR file to make this work. You can download it even if you do not have Java Edition, the original Mojang download links are available on GitHub, scroll right to see the client JARs.
Assigning Java block models to Bedrock blocks is controlled by config/bedrockmapping.json. The content of this file is largely based on information extracted from the Chunker project.
Bedrock fences, stairs, glass panes and other connecting blocks may render incorrectly if you have a version older than 1.26.40, because the required information is not present in the world save files.
This is a preview of a new feature under development.

uNmINeD now can render 3D block models to draw blocks instead of using single colors.
Use the --blockrender=true command line parameter to enable block model rendering in the CLI.
This is a preview of a new feature under development.

uNmINeD now can render an βisometricβ (axonometric) 3D map.
Block model rendering is a new feature under development. There are a lot of bugs, glitches and unfinished stuff. The code is not yet optimized for speed, upcoming releases will be faster.
Some of the most visible known problems:
0 (#11249, closed #10623).www counterpart domains and corrected domain guidance and mobile domain visibility.Full Changelog: v4.3.1...v4.3.2
The PostgreSQL Global Development Group has released an update to all supported versions of PostgreSQL, including 18.6, 17.11, 16.15, 15.19, and 14.24, as well as the third beta release of PostgreSQL 19. This release fixes 28 security vulnerabilities and over 110 bugs reported over the last several months.
This release skips PostgreSQL 18 versions from PostgreSQL 18.4 to 18.6. 18.5 was not shipped due to a regression.
There are three issues that may require you to take extra steps after updating, which are described in detail below. These issues are related to:
btree_gistltreeFor the full list of changes, please review the release notes.
PostgreSQL 14 will stop receiving fixes on November 12, 2026. If you are running PostgreSQL 14 in a production environment, we suggest that you make plans to upgrade to a newer, supported version of PostgreSQL. Please see our versioning policy for more information.
The following security vulnerabilities are closed across in this update release. You can find more details about the vulnerabilities and their affected versions in the links below:
This update fixes over 110 bugs that were reported in the last several months.
This specific issue only affects PostgreSQL 14, 15, and 16, but we're highlighting it in the release announcement due to its severity:
The remainder of issues listed below affect PostgreSQL 18. Many of these issues also affect other supported versions of PostgreSQL.
reltuples value in pg_class.
Previously, a parallel worker could report an uninitialized row count, leaving
reltuples set to a bogus value (including Infinity or NaN). Such a
value can cause autovacuum and autoanalyze to not process the table, and this
situation will not self-correct. If you have any tables with GIN indexes,
we recommend checking that their reltuples values look reasonable after
updating. See the "Updating" section for how to identify and repair affected
tables.btree_gist,
including for NaN handling for float4/float8 that could give wrong
answers for columns containing NaN and correct sorting of bit/bit varying
values during index building. You may need to reindex btree_gist
indexes on float or bit columns after updating. See the "Updating" section.ltree comparisons.
ltree values containing more than about 14,653 labels could compare
incorrectly, which could present as a corrupt B-tree index. If you use ltree,
you may need to reindex affected indexes after updating. See the "Updating"
section.RANGE-partitioned tables so the DEFAULT partition is no longer skipped in
cases where it should be scanned. Previously this could cause rows to be missing
from query results.RETURNING with
OLD and NEW.NULL values.value IN (array) tests where the array might be empty, and COUNT() window
functions that use an EXCLUDE clause or lack ORDER BY.REINDEX
CONCURRENTLY on an
index backing a deferred uniqueness constraint, which could cause false
constraint-violation reports.LIKE or
regular-expression exact-match pattern into an equality index condition when the
index and expression collations differ.jsonpath,
including that the @? and @@ operators now correctly raise an error for an
undefined variable in the path expression. Previously, because these operators
cannot supply variable values, an undefined variable was treated as a JSON
null rather than an error, which could also lead to unbounded memory
consumption."no empty local buffer available" errors during temporary table access
when a large effective_io_concurrency
setting could allow a single read stream to consume all local buffers.VACUUM's
wraparound failsafe mode to use the full shared buffer pool as intended, which
had slowed down emergency vacuuming.SERIALIZABLE
isolation. A conflict could be missed when examining an initially-empty btree
index, allowing conflicting transactions to commit and breaking serializability.COMMIT PREPARED or ROLLBACK PREPARED to the output plugin with no
preceding PREPARE, which breaks replication for the built-in subscriber.libpq,
including ensuring it drains all pending bytes from the SSL or GSS decryption
buffer when reading data, avoiding cases where a client waits for data that has
already arrived.pg_createsubscriber
to clean up objects left on a publisher after failure, including a replication
slot.pg_restore
with --statistics or --statistics-only so that, when combined with other
selective-restore options such as --schema, it restores the expected items,
matching the behavior of pg_dump.This release also updates time zone data files to tzdata release 2026c, in which Alberta (America/Edmonton) will be on year-round UTC-06 (effectively, permanent DST) beginning in November 2026. This release assumes that their TZ abbreviation will be CST from that time forward (though this could change). It also reflects that Morocco (Africa/Casablanca) will move to permanent UTC+00, without daylight saving transitions, on September 20, 2026.
All PostgreSQL update releases are cumulative. As with other minor releases,
users are not required to dump and reload their database or use pg_upgrade
in order to apply this update release; you may simply stop PostgreSQL and
update its binaries.
If you have any tables with GIN indexes, we recommend checking their reltuples
values after updating. A prior bug in parallel GIN index builds could have left
reltuples set to a bogus value (including Infinity or NaN) that prevents
autovacuum and autoanalyze from ever processing the table. The following query
lists the tables that have a GIN index, along with their current reltuples:
SELECT DISTINCT t.oid::regclass, t.reltuples
FROM pg_class t
JOIN pg_index i ON t.oid = i.indrelid
JOIN pg_class ic ON i.indexrelid = ic.oid
WHERE t.relhasindex AND ic.relam = 2742;
For any table whose reltuples value looks incorrect, run
ANALYZE on it (or
create another index) to reset the value.
If you use btree_gist, you should reindex btree_gist indexes on float4 or
float8 columns that might contain NaN values, as well as btree_gist indexes
on bit or bit varying columns, for example:
REINDEX INDEX your_index_name;
If you use ltree and have btree indexes over ltree values with very many
labels (more than about 14,653), you should
reindex those
indexes, since they may be corrupt, for example:
REINDEX INDEX your_index_name;
Users who have skipped one or more update releases may need to run additional post-update steps; please see the release notes from earlier versions for details.
For more details, please see the release notes.
This release marks the third beta release of PostgreSQL 19.
In the spirit of the open source PostgreSQL community, we strongly encourage you to test the new features of PostgreSQL 19 on your systems to help us eliminate bugs and other issues. While we do not advise you to run PostgreSQL 19 Beta 3 in production environments, we encourage you to find ways to run your typical application workloads against this beta release.
Your testing and feedback helps the community ensure that PostgreSQL 19 upholds our standards of delivering a stable, reliable release of the world's most advanced open source relational database. Please read more about our beta testing process and how you can contribute:
https://www.postgresql.org/developer/beta/
To upgrade to PostgreSQL 19 Beta 3 from an earlier version of PostgreSQL,
you will need to use a strategy similar to upgrading between major versions of
PostgreSQL (e.g. pg_upgrade or pg_dump / pg_restore). For more
information, please visit the documentation section on
upgrading.
Fixes and changes in PostgreSQL 19 Beta 3 include:
GROUP BY ALL.FOR PORTION OF temporal table syntax.REFRESH SEQUENCES.postgres_fdw when pushing down an array
comparison such as field = ANY($1) that involves an implicit type coercion.UNIQUE constraint.pg_plan_advice parsing of underscores in numeric literals.FORMAT clause when deparsing JSON_ARRAY(query).Please see the release notes for a complete list of new and changed features:
https://www.postgresql.org/docs/19/release-19.html
The stability of each PostgreSQL release greatly depends on you, the community, to test the upcoming version with your workloads and testing tools to find bugs and regressions before the general availability of PostgreSQL 19. As this is a Beta, minor changes to database behaviors, feature details, and APIs are still possible. Your feedback and testing will help determine the final tweaks on the new features, so please test in the near future. The quality of user testing helps determine when we can make a final release.
A list of open issues is publicly available in the PostgreSQL wiki. You can report bugs using this form on the PostgreSQL website:
https://www.postgresql.org/account/submitbug/
If you have corrections or suggestions for this release announcement, please send them to the pgsql-www@lists.postgresql.org public mailing list.
Full Changelog: v4.3.0...v4.3.1
24.0.0-pre1
Let us know what you think about the new UI here: #11195
GET requests now return 405 Method Not Allowed. This affected /enable, /disable, /deploy, server validation, application/database/service lifecycle actions, and service-application lifecycle actions (v4.2.0).www redirects for applications using Traefik.Full Changelog: v4.2.0...v4.3.0
If you are upgrading from v0.16.x, replace the binary (or run docker pull). If you are upgrading from v0.15.x and below, please read the upgrading documentation for more information on how to upgrade from previous versions.
Range and If-Range header support on file downloads (RFC 7233) (#2377).url_original expression variable for Url rules.jemallocator crate with tikv-jemallocator (contributed by @checkraisefold).description as label property.FUTURERELEASE HOLDUNTIL uses Unix timestamps instead of RFC 3339 date-times.EmailSubmission/query filtering on undoStatus contradicts EmailSubmission/get, reporting held FUTURERELEASE submissions as final instead of pending.EmailSubmission/get requests without an ids argument iterates the wrong index.Accept: text/vcard version negotiation is ignored whenever another parameter such as q or charset follows version=.text/calendar part outside the multipart/alternative and disposed as an attachment.impersonate permission never have their ACL grants collected, so shared items are never listed in JMAP sessions, CalDAV/CardDAV discovery or IMAP.COPY/MOVE into a shared folder fails with NO [ALREADYEXISTS] when the destination account already holds the message, leaving the message in the source mailbox and clients in a retry loop.BODYSTRUCTURE and ENVELOPE return MIME parameters, Content-Description, subjects and display names as raw UTF-8 even to sessions that never enabled UTF8=ACCEPT.
[An on-line version of this announcement will be available at https://www.postfix.org/announcements/postfix-3.11.6.html]
This release addresses medium-impact problems that need to be fixed as some enable remote DOS or policy bypass.
The fixes below, and more, are also released in the unstable version postfix-3.12-20260809.
In addition to updated releases for the supported Postfix versions 3.8-3.11, releases will also be available for the out-of-support Postfix versions 3.5-3.7. NOTE: these do not include the patches for out-of-support Postfix versions that have been issued for "large SMTP inputs (June 2026)", "TLSA parsing (June 2026)", and "SMTP smuggling fixes". Those patches still need to be applied.
These defects were found by Qualys assisted by Claude Mythos Preview, and by OpenAI Security; more than half date from 20 or more years ago. When I implemented Postfix, I knew that there were going to be mistakes. That is the reason why Postfix has its architecture and safety nets. The number of defects may seem large, but considering that they were found in a code base of over 150 thousand lines, the error rate is still lower than what I designed for.
Policy bypass:
Bug (introduced: Postfix 2.2, date: 20041102): missing SMTP server resets of MAIL FROM and RCPT TO command state after smtpd_end_of_data_restrictions rejected a message. This resulted in SMTP protocol state desynchronization between the remote SMTP client and the Postfix SMTP server.
A crafted remote SMTP client could then send RCPT TO and DATA without MAIL FROM, and deliver a second message. Then, smtpd_end_of_data_restrictions skipped check_recipient_access constraints, because a recipient counter was > 1. Reported by OpenAI Security. File: smtpd/smtpd.c.
As reported by OpenAI Security, the failure to reset MAIL FROM and RCPT TO state also affected Milter support (added in Postfix 2.3). Here, after a Milter replied with "accept this message" based on the message envelope, and smtpd_end_of_data_restrictions rejected the message, the Postfix SMTP server as before accepted RCPT TO and DATA without MAIL FROM, and smtpd_end_of_data_restrictions as before skipped check_recipient_access constraints for the second message. Under these conditions, the Postfix Milter client remained in the "accept this message" state, skipping Milter policy enforcement for the second message.
Denial of service:
Bug (defect introduced: Postfix 3.4, date: 20180805): SMTP server command history memory exhaustion with a large number of very small BDAT requests. Reported by OpenAI security. File: smtpd.c.
Bug (defect introduced: Postfix 1.1, date: 20021116): address verification cache poisoning. A local user could use the postdrop command to submit an address verification probe with envelope or message content that Postfix rejected later, resulting in a negative address verification cache entry for that address. On systems that enable address verification, the negative address verification cache entry would force the Postfix SMTP server to reject a message that it should accept (denial of service). Problem reported by OpenAI Security. File: postdrop.c.
Server crashes and panic()s:
Bug (defect introduced: Postfix 3.4, date: 20180805): missing SMTP server reset of RCPT TO state, after a BDAT command error. A crafted remote SMTP client could then send a DATA command without MAIL FROM or RCPT TO, and crash a Postfix SMTP daemon process with a null pointer read error. Reported by OpenAI Security. File: smtpd/smtpd.c.
Bug (defect introduced: Postfix 2.4, date: 20051222): null pointer read crash while parsing a malformed Dovecot AUTH server response. Reported by Qualys, assisted by Claude Mythos Preview. File: xsasl_dovecot_server.c.
Read after free, uninitialized read, under/over read:
Bug (defect introduced: Postfix 2.8, date: 20100914): read-after-free in the PSC_CALL_BACK_NOTIFY() macro. This had no effect on program execution, because myfree() wiped memory, and that memory was not yet reused. Problem reported by Qualys, assisted by Claude Mythos Preview. File: postscreen_dnsbl.c.
Read after free (no privilege escalation) in debug logging (defect introduced: Postfix 2.2, date: 20050117). Reported by Qualys, assisted by Claude Mythos Preview. File: util/inet_connect.c.
Bug (defect introduced: Postfix 2.10, date: 20120617): uninitialized memory read in postscreen HaProxy client after remote I/O exception, causing garbage to be logged. Reported by Qualys, assisted by Claude Mythos Preview. File: postscreen_haproxy.c.
Latent bug (defect introduced: Postfix 2.7, date: 20090618): uninitialized memory read after dnsblog(8) returns a string that is not an IPv4 address. Reported by Qualys, assisted by Claude Mythos Preview. File: postscreen_dnsbl.c.
Bug (defect introduced: before Postfix alpha, date 19970424): the DNS client could read up to two bytes past the end of an MX record, before discovering that the record was too short. This behavior was later copied with SRV records, potentially over-reading up to six bytes. Problem reported by Qualys, assisted by Claude Mythos Preview. File: dns_lookup.c.
Bug (defect introduced: Postfix 1,1, date: 20010524): the postsuper command under-read or over-read a very short queue filename. No crash, information leak, or privilege escalation. Reported by Qualys, assisted by Claude Mythos Preview. Files: postsuper.c, mail_queue.h.
Other code hygiene:
Bug (defect introduced: before Postfix alpha, date: 19971106): 'int' over-shift, in the queue file record-length parser. Postfix programs do not generate such records, but an attacker could cause postdrop to reject input or panic(). Reported by Qualys, assisted by Claude Mythos Preview. File: record.c.
Bug (defect introduced: Postfix 2.2, date: 20050117): non-transitive comparison of IPv4 addresses. Reported by Qualys, assisted by Claude Mythos Preview. File: sock_addr.c.
Bug (defect introduced: Postfix 1.0, date: 20000928): the fast flush server, used by the SMTP command "ETRN", and by the commands "postqueue -s site" and "postqueue -i queue_id" (and their sendmail(1) equivalents), used the wrong duplicate suppression API, resulting in unnecessary queue scans by the queue manager. Reported by Qualys, assisted by Claude Mythos Preview. File: flush.c.
Queue hygiene: the postdrop command accepted the null record type which the rest of Postfix ignores. Reported by OpenAI Security. File: postdrop.c.
You can find the updated Postfix source code at the mirrors listed at https://www.postfix.org/.
The Asterisk Development Team would like to announce
the release of Certified asterisk-22.8-cert4.
The release artifacts are available for immediate download at
https://github.com/asterisk/asterisk/releases/tag/certified-22.8-cert4
and
https://downloads.asterisk.org/pub/telephony/certified-asterisk
Repository: https://github.com/asterisk/asterisk
Tag: certified-22.8-cert4
This release resolves issues reported by the community
and would have not been possible without your participation.
Thank You!
The Asterisk Development Team would like to announce
release candidate 1 of asterisk-23.5.0.
The release artifacts are available for immediate download at
https://github.com/asterisk/asterisk/releases/tag/23.5.0-rc1
and
https://downloads.asterisk.org/pub/telephony/asterisk
Repository: https://github.com/asterisk/asterisk
Tag: 23.5.0-rc1
This release resolves issues reported by the community
and would have not been possible without your participation.
Thank You!
The Asterisk Development Team would like to announce
release candidate 1 of asterisk-22.11.0.
The release artifacts are available for immediate download at
https://github.com/asterisk/asterisk/releases/tag/22.11.0-rc1
and
https://downloads.asterisk.org/pub/telephony/asterisk
Repository: https://github.com/asterisk/asterisk
Tag: 22.11.0-rc1
This release resolves issues reported by the community
and would have not been possible without your participation.
Thank You!
The Asterisk Development Team would like to announce
release candidate 1 of asterisk-20.21.0.
The release artifacts are available for immediate download at
https://github.com/asterisk/asterisk/releases/tag/20.21.0-rc1
and
https://downloads.asterisk.org/pub/telephony/asterisk
Repository: https://github.com/asterisk/asterisk
Tag: 20.21.0-rc1
This release resolves issues reported by the community
and would have not been possible without your participation.
Thank You!
VIENNA, Austria β August 05, 2026Β βEnterprise software developer Proxmox Server Solutions GmbHΒ today announced the immediate availability of the first officially supported Arm64 edition of its flagship platform, Proxmox Virtual Environment. The release extends the open-source virtualization platform to Arm-based server systems, supporting enterprise demand for high-density, energy-efficient data center architectures.
Proxmox VE for Arm64 provides a unified platform to manage Arm64 virtual machines and Linux containers (LXC). Users benefit from the established web-based management interface, software-defined networking, storage, high-availability clustering, and backup capabilities of Proxmox VE on supported Arm64 hardware.
Systems based on the NVIDIA Grace and NVIDIA Vera CPU architectures are supported from the first official Arm64 release. These platforms target demanding data center, cloud, accelerated computing, and AI training and inference environments, expanding the infrastructure options available to organizations building modern and energy-efficient data centers.
Technical validation on NVIDIA Grace Hopperβ’ systems
Developed in technical collaboration with NVIDIA and Supermicro, Proxmox engineers performed joint validation on NVIDIA Grace Hopperβ’ Superchip server systems. This effort enabled rapid porting and thorough testing across the platform stack, which is already operating across select enterprise production environments.
Full feature parity for ZFS and Ceph
Built on Proxmox VEβs established Linux and KVM foundation, the Arm64 edition underwent architecture-wide validation. Key enterprise storage mainstays β including ZFS and Ceph β have been fully optimized to deliver exact performance, reliability, and feature parity with existing x86 deployments.
βAs data centers shift toward high-density, energy-efficient architectures, our customers require the exact same mission-critical stability on Arm64 that they have relied on with x86," said Tim Marx, COO at Proxmox Server Solutions. "Through our close engineering work with NVIDIA and Supermicro, we are ensuring that enterprises can scale their next-generation AI and cloud workloads with complete confidence in their underlying hypervisor."
βOur goal was not simply to run Proxmox VE on a new architecture, but to deliver full feature parity: KVM, networking, clustering, ZFS, and Ceph all behaving exactly as our users expect from our x86-64 builds,β said Thomas Lamprecht, CTO at Proxmox Server Solutions. βDeveloping directly on NVIDIA Grace Hopper systems let us validate that on production-class hardware from day one, and NVIDIA's upstream kernel work ensures the platform evolves alongside NVIDIA Grace and NVIDIA Vera.β
Proxmox Virtual Environment for Arm64 is open-source software and immediately available for download via bare-metal ISO images or package repositories alongside existing x86-64 builds.
For enterprise environments, Proxmox Server Solutions offers comprehensive support plans that provide stable and secure updates and direct access to expert support services. These support contracts offer a cost-effective way to secure enterprise-grade stability. Enterprise support for Arm64 deployments are available upon request.
Resources:
###
About Proxmox Virtual Environment
Powering over 2 million hosts globally, Proxmox Virtual Environment is a complete open-source platform for enterprise virtualization and hyper-converged infrastructure. It natively unifies KVM virtualization, LXC containers, software-defined storage, and networking on a single platform. Alongside its dedicated Backup Server and Datacenter Manager, the Proxmox ecosystem eliminates multi-site complexity as well as dependency on proprietary stacks. Backed by a global community of over 225,000 members, the platform serves as a scalable, cost-effective foundation for modern data centers.
About Proxmox Server Solutions
Proxmox Server Solutions provides powerful, intuitive open-source server software that guarantees vendor independence and minimizes total cost of ownership. Enterprises of all sizes rely on the companyβs reliable vendor support, certified training services, and a global network of 3,000 integration partners to ensure business continuity. Established in 2005 and headquartered in Vienna, Austria, tens of thousands of corporate customers worldwide trust Proxmox solutions to secure their mission-critical IT environments.
Contact:Β Daniela HΓ€sler, Proxmox Server Solutions GmbH, press@proxmox.com
General
Media-Over-QUIC
General
Media-Over-QUIC
RTSP
RTMP
HLS
WebRTC
SRT
Dependencies
Binaries are compiled from source code by the Release workflow, which is a fully-visible process that prevents any change or external interference in produced artifacts.
Checksums of binaries are also published in a public blockchain by using GitHub Attestations, and they can be verified by running:
ls mediamtx_* | xargs -L1 gh attestation verify --repo bluenviron/mediamtx
You can verify checksums of binaries by downloading checksums.sha256 and running:
cat checksums.sha256 | grep "$(ls mediamtx_*)" | sha256sum --check
If you are upgrading from v0.16.x, replace the binary (or run docker pull). If you are upgrading from v0.15.x and below, please read the upgrading documentation for more information on how to upgrade from previous versions.
orcpt during the DATA stage.accessKey can now be read from an environment variable or file.GET instead of creating a new task which times out on busy servers.LF line endings, producing a single 4247 octet line that strict SMTP relays reject with line too long.Identity-Alignment: none when a mechanism authenticated successfully but against an identity that is not aligned with the From domain.BDAT chunks sent without a valid MAIL FROM are answered with 552 5.3.4 Message too big for system instead of 503 5.5.1.maxMessageSize of 0 rejects every message with 552 5.3.4 Message too big for system instead of disabling the size limit.[::]), including all defaults, refuse IPv4 connections such as 127.0.0.1, since IPV6_V6ONLY is enabled by default on Windows.