Loading article…
FiveMesh V2 is here
A rebuilt dashboard, a clearer home for every Server and service, and a new foundation for the next stage of FiveMesh.
A rebuilt dashboard, a clearer home for every Server and service, and a new foundation for the next stage of FiveMesh.
Loading article…
FiveMesh V2 is the largest evolution of FiveMesh so far. We began by asking how to make the dashboard easier to use. That question quickly became a bigger one: how should FiveMesh work when a community has several Servers, several people managing them, and more infrastructure to operate than one sidebar can comfortably hold?
The answer became V2. CDN, Cache, Voice and Logs remain the services you know. The experience around them has been rebuilt, and so has a large part of the foundation that creates, connects and manages them. You should notice the new dashboard immediately. The deeper change is that FiveMesh now has a clearer way to grow without making everyday work more complicated.
The first version helped us learn where the friction really was. Some of it was visible: moving between products took too much orientation, and an unconfigured service did not always tell you how to begin. Some of it sat behind the interface: the original model made it harder to give each Server a clear identity and to keep long-running service operations understandable. A new coat of paint would have left those problems in place. We chose to rebuild the parts that shaped them.
The new application is designed around the work server owners actually do: choose a Server, see the state of its services, make a change, and understand what happened. The navigation is quieter, page headings tell you where you are, and related controls behave more consistently across products. Light and dark themes have both been treated as complete experiences, with responsive layouts for smaller screens and clearer focus and loading states as you move through the app.
There is less guessing when a service has not been set up. Previously, an inactive product could feel like an empty management page. In V2, CDN, Cache, Voice and Logs each have a proper starting point: what the service does, what you need to begin, and the action that takes you there. Once it is active, the same page becomes the place to operate it. Provisioning and deletion also have visible states instead of leaving you to infer whether a click worked.
The dashboard shares the restrained visual language of the current FiveMesh site, but it has its own job. It is an operational surface. The design should help you find a setting or spot a problem, then get out of the way.
The simplest way to understand V2 is Organization → Server → Service.
Your Organization holds the account relationship: its subscription, members and shared resources. Servers live directly inside it. Cache, Voice and Logs are attached to a Server. CDN stays at the Organization level because public images, video and other hosted assets can serve more than one FiveM Server.
That structure now shows up in the way you navigate. Pick a Server in the new switcher and move from Cache to Voice or Logs without selecting it again. If you switch Servers while looking at one of those services, the dashboard keeps you in that service and shows the newly selected Server. CDN remains in the same place regardless of which Server is selected.
Available across the Organization
Select once, then move between its services
This is more than a shorter path through a menu. A community with several Servers can now separate the work that belongs to each one from the resources they share. It also makes links to a particular Server and service useful when a teammate needs to jump straight into a problem.
Imagine checking Cache traffic on your main roleplay Server, then opening Voice to confirm its endpoint, then looking at yesterday's Logs. Those pages belong to the same selected Server. If you switch to a testing Server while in Logs, you stay in Logs but see the testing Server's source. The Organization's CDN files do not move with that switch. This sounds small until you spend a day moving between services; keeping the context right is what makes one dashboard feel like one platform.
The service navigation has room to expand. Delivery contains CDN and Cache; Realtime contains Voice; Observability contains Logs. Those labels organize what is already here, and give future services a logical home without turning the sidebar into a long, flat list.
V2 improves the daily work inside each product, not just the route used to reach it.
The CDN object browser has a more direct path from a file on your computer to a hosted object. You can upload files or folders, organize objects in folders, and preview supported files before using their public URLs. Search now looks across stored CDN objects rather than only the items the browser has already loaded. That matters once a bucket is too large to scan by scrolling.
Creating a CDN service and removing one are also clearer processes. The dashboard reports provisioning state, offers a retry when setup fails, and shows scheduled deletion and its progress. These are moments where uncertainty is especially expensive: you need to know whether an upload, setup or cleanup is still happening before trying again. The object browser, search and lifecycle states are designed to make that visible.
For a team hosting inventory images, phone media and NUI assets together, the improvement is straightforward. You can keep the files organized by purpose, search for an object even if it is not in the current browser page, inspect a supported preview, and then copy or use its public path. Recent uploads may take a moment to appear in search while the index catches up; browsing and upload feedback remain available in the meantime.
If CDN is new to your team, the CDN overview and setup guide cover the publishing workflow in more detail.
Cache now follows the selected Server, so the configuration and analytics you see belong to the Server you are working on. Activation begins with an explanation of the service and a clear path to enabling it. The setup flow is more deliberate about the origin that FiveMesh fetches from, including trusted origin options where available. The dashboard distinguishes setup and synchronization states from a working Cache, and gives you a clearer place to check configuration or correct a problem.
The analytics view lets you choose a time range supported by your plan and inspect requests, delivery and origin behavior. It is a practical way to understand whether Cache is helping after a resource update or a busy weekend. Cache still does the familiar job: serving resource downloads while reducing repeated traffic to the origin. V2 makes that job easier to set up and observe. The Cache setup guide remains the place for the FXServer configuration details.
Voice instances are now part of the same Server-centered flow. You choose a region when creating an instance, then see its provisioning state, connection endpoint and configuration in the management view. The page distinguishes an instance that is still being prepared from one ready for player connections, and presents status and heartbeat information where available. When an operation needs attention, the dashboard exposes the relevant retry or management action.
The underlying Voice nodes are still dedicated infrastructure. V2 does not move player audio into the dashboard or a Cloudflare Worker. It improves the control experience around that infrastructure: creating an instance, seeing where it lives, connecting PMA-Voice, restarting it and understanding its state. The Voice overview explains the product itself.
Logs no longer starts with the old Early Access acknowledgement. For eligible plans, the Organization owner can enable it directly, then add a Logs source for the selected Server. The active service is organized around Explorer, Analytics and Settings, so searching events, understanding ingestion and managing the connection each have a clear place.
Settings shows the ingestion endpoint resolved for that Server, along with the service state and a route to the setup guide. You can disable a source without deleting its configuration. Disabling stops new ingestion, while events already collected remain searchable for their normal retention period. Deleting the source is a separate action with different consequences. That distinction makes it easier to pause a connection, investigate an issue and decide what to do next.
Logs is meant to shorten the distance between “something went wrong” and the event that explains it. The Logs overview and setup guide cover what to send and how to connect a Server.
V2 makes the Organization the clear owner of the FiveMesh relationship. It is where owners manage members and invitations, while personal Account settings stay separate. A member can be given access to all Servers or only selected Servers. That is useful when a staff member looks after one community Server but should not see every environment the Organization runs.
This separation also makes handoffs less awkward. An owner can manage the subscription and shared resources at the Organization level, while a teammate works in the services for the Servers they are assigned. The dashboard reflects those relationships instead of requiring everyone to keep a mental map of which setting belongs to a person, a team or a Server.
Billing now presents the commercial picture in one place. The plan and subscription sit alongside three primary usage resources: Storage, Requests and Bandwidth. CDN and Cache still provide service-level breakdowns, so you can see where usage came from. The main allowances are shared across the platform rather than asking you to manage separate request and bandwidth limits for each delivery service. We covered the model and its rollout in our usage and billing article; V2 makes that model easier to read in the dashboard.
API keys have a clearer context too. When creating a developer key, you can choose an Organization-wide context where appropriate, or bind it to a specific Server, then review its allowed actions before creating it. Server-specific keys give integrations a more focused scope. There is also a Server API Key flow on the Server itself for the services that need a Server credential. This is the kind of distinction that should be obvious while setting up an integration, rather than discovered after a key has already been copied into a resource.
We could not make all of these changes by rearranging the dashboard. Behind it is a significantly rebuilt control plane, with much of the platform's application state, orchestration and background work now running on Cloudflare's developer platform. Cloudflare Workers, D1, R2, Workflows and Queues are parts of that foundation. They are not the whole of FiveMesh: billing still involves Polar, and Voice still runs on dedicated nodes.
What matters to customers is how work behaves. Provisioning can continue after the browser request ends. A failed operation can be retried with a clearer record of what has already happened. Cleanup and synchronization can run in the background instead of being hidden inside a dashboard load. The application can show a more honest service state while that work is in progress. These improvements do not make infrastructure infallible; they make it easier to operate and recover when something does go wrong.
That distinction matters during ordinary operations as much as during incidents. When you enable a service, a network request finishing is not the same as the service being ready. V2 gives the platform a better way to carry that work through, report its state and finish it even if you leave the page. It also gives us a clearer place to improve the process as real usage exposes edge cases.
The architecture behind V2 deserves its own article. We will publish a developer-focused account shortly after launch, including why our first V2 tenancy model was removed, how we moved much of the control plane from MongoDB and VPS-oriented services to Workers and D1, and what it took to build CDN search over R2. It will also cover Queue ordering, migration edge cases, local D1 development, and the CORS and CSP surprises we met along the way. There were decisions we would repeat and others we would change. That story is worth telling properly.
V2 gives the existing services a more coherent home today. It also gives the next ones a better starting point: a clear Organization and Server model, service lifecycles that can be seen and managed, and navigation that can accommodate more Delivery, Realtime and Observability work as FiveMesh grows. We are not announcing new services in this post. We are making sure the platform can welcome them without asking customers to relearn how everything fits together.
Our goal remains a unified infrastructure platform for FiveM communities. V2 is the foundation for that next stage. Open the new dashboard and take a look around.