As cloud environments grow, outbound internet traffic often grows with them. Each virtual network gets its own public-facing path, its own translation service, and a slightly different set of firewall rules. That works for a small estate. It becomes difficult to audit when several accounts, subscriptions, regions, and application teams are involved.

A centralized egress design moves outbound traffic through a small number of controlled inspection points. Workload networks remain private, security policy has a clear enforcement location, and the organization can record which networks are allowed to reach the internet. The design does not remove the need for workload-level controls. It gives those controls a network path they can actually rely on.

Ingress-NGINX reached retirement on 24 March 2026. The Kubernetes Steering and Security Response Committees say there will be no further releases, bug fixes, or security patches for the project. That does not mean every cluster must replace its ingress controller during an incident, but it does mean that keeping it as an Internet-facing dependency needs an explicit migration plan.

This guide converts a small, ordinary Ingress-NGINX route set into Gateway API resources without deleting the existing ingress. The finished result is a reviewed Gateway and HTTPRoute manifest, attached to a controller-supported GatewayClass, with a test request that proves the hostname, path, backend, and TLS behavior before traffic is moved. The commands are documentation-verified examples, not output from a particular cluster. Use a maintenance window and adapt the controller installation, load-balancer addresses, namespace names, and DNS records to the platform you operate.

GitHub’s AI security detections can place a new class of finding beside ordinary code-scanning results when a pull request is opened or updated. That can be useful for teams maintaining AI-assisted or conventional application code, but it is not a reason to let an automatically generated finding change a production branch by itself. GitHub describes these detections as informational: they do not block a merge, and they depend on GitHub Code Security plus CodeQL default setup.

npm v12 changes what an ordinary dependency install is allowed to do. Its new defaults leave dependency lifecycle scripts disabled unless they are explicitly approved, and they refuse Git and remote-URL dependencies unless those dependency sources are explicitly allowed. That is a useful supply-chain boundary, but it can also make a familiar npm ci fail to produce a usable application when a native module, generated client, or other dependency normally prepares itself during installation.

OpenSSH 10.4, released on 6 July 2026, includes security fixes and makes the SSH transport protocol stricter. That combination is a good reason to plan an update, but it is also a reason not to treat a remote-access service like an ordinary package refresh. A syntactically valid sshd_config can still lock out the only administrator who has the required key, source address, or jump host path.

This guide prepares a Linux host for a distribution-provided OpenSSH 10.4 update. The result is a recorded effective server configuration, a tested administrative connection, and a rollback-safe update sequence. The commands are documentation-verified examples, not observations from a particular host. Run them from a console, out-of-band management session, or a second SSH session that remains open until the new daemon has accepted a fresh connection.

The old IP Filter article in this archive reflects an earlier FreeBSD firewall workflow. For a new FreeBSD host, start with PF and make the first policy deliberately small: retain console access, permit only the services the host provides, and validate the rules before enabling them at boot.

This is a documentation-verified baseline, not a copy-and-paste production policy. Interface names, management networks, service ports, IPv6 needs, and routing requirements vary by host. Apply it first from a console or an out-of-band management path so a typo does not strand an SSH-only system.

Renaming a FreeBSD account is more than changing a login name. A safe change preserves the numeric UID where possible, updates the primary group when appropriate, moves the home directory, repairs ownership, and checks files or scheduled jobs that still reference the old name.

Plan the change during a maintenance window. Do not rename an account that is actively logged in, owns a running service, or is the only administrative access path to the host. Keep a root or separate administrator console session open until the new account has been tested.

bhyve is part of the FreeBSD base system and remains a practical choice when a FreeBSD host needs to run a small number of FreeBSD, Linux, OpenBSD, or Windows guests. This article updates the older FreeBSD 10.1 walkthrough with the workflow documented in the current FreeBSD Handbook. It deliberately uses the base-system example script rather than presenting an untested production framework.

The outcome is a FreeBSD guest connected to the same Layer-2 network as the host through a tap device and bridge. The commands are documentation-verified examples. Substitute the physical interface, guest name, disk location, memory, CPU count, and ISO release for your host.

The 23 July etcd patch release fixed a watch authorization problem that could disclose events outside a user’s RBAC key range. The fix is available in v3.7.1, v3.6.14, and v3.5.33. This is a good reason to patch, but the release is also a useful reminder that an etcd maintenance window should prove more than a new binary starts.

This guide is for an administrator of a self-managed, TLS-enabled three-member etcd cluster. The finished result is a patched cluster with a verified endpoint health check, a recorded member view, and an off-node snapshot whose integrity has been checked. The commands are documentation-verified examples, not output from a production cluster. Replace the certificate paths, endpoint addresses, service name, package method, and backup location with values from your own installation.

A pull request workflow often needs two things that should be kept separate: untrusted code to test and trusted repository credentials to comment, label, publish, or update a status. GitHub’s June 2026 actions/checkout changes made one dangerous combination harder to enable by accident, but they do not turn every pull request workflow into a safe deployment workflow.

This guide builds a review workflow that tests pull-request code with the least useful token possible, then shows the narrow case where pull_request_target is appropriate. The successful result is easy to inspect: a pull request runs the contributor’s code without repository write permissions, while a trusted follow-up job can add a label without checking out that code.