Yasa Nexus brings assigned websites, game servers and infrastructure resources into one hosting administration panel. It gives the people responsible for those services a place to inspect their state, use the available controls and follow the results. Access is invitation-only, with permissions tied to the resources and actions each person may manage.
That makes the distinction between using a service and administering it clear. A visitor can browse a hosted business website, and a player can join a public game server through its normal connection. Meanwhile, the people managing that infrastructure enter Nexus with the appropriate invitation and verified identity.
What Yasa Nexus manages
The platform brings three kinds of work together: website hosting, game-server management and infrastructure administration. However, each resource keeps its own context. A staging website, a live store and a game world can have different owners, permissions and recovery needs, even when they appear in the same panel.
For websites, projects and environments help organise the route to the intended site. Game-server views bring the selected server’s console, files, settings and supported operations together. In addition, authorised infrastructure administrators can inspect broader system resources. The controls available to you depend on your role and assignments.
Start with the Nexus platform introduction if you are arranging hosting. If you are planning the website itself, our Yasa websites and digital services guide explains the design, build and handover conversation. Hosting administration and website delivery have connected but distinct responsibilities.
How access to Yasa Nexus works
First, an authorised administrator invites the exact supported Google identity and assigns the relevant resources. You then sign in using that Google or Google Workspace account. Your role controls the actions you can perform, while the assignment identifies where those actions apply. The Nexus access guide explains this entry process.
A public Yasa account does not grant infrastructure administration. Likewise, joining a project in another application does not make you a hosting administrator. This separation lets a team collaborate on content or tasks while keeping server operations with the people responsible for them.
If an expected website or server is missing, ask the resource administrator to check your identity, invitation and assignment. Also confirm that you are looking for the correct environment. A similarly named resource is not a suitable substitute when files, databases or live services are involved.
Follow a clear website workflow
Use Yasa Nexus to find the website project first. Next, check the domain and deliberately choose its staging or production environment. Open Manage website to inspect the controls and state available for that resource. The website and environment guide describes this route.
Website hosting also includes separate database and hosted-mail controls for the intended hosting account. Confirm the account and domain, inspect the existing resources and use the operation your role permits. For mail, also verify the domain’s DNS and delivery requirements with its administrator. A saved mailbox record still needs a working delivery setup. For everyday mailbox use, our Webmail guide explains sign-in, folders and messages.
For example, consider a team preparing a change to a live business site. It can review the change on the intended staging environment, check the relevant visitor journeys and agree the release scope. The person responsible for production then performs the appropriate authorised operation and verifies the public result. This is an illustrative workflow; the available tools depend on the site and access.
A project record helps organise this work, but the website still needs its actual files, configuration, domain and working application. Therefore, open the environment URL and inspect the site itself. For a WordPress change, our upgrade preparation guide explains how a baseline, staged checks and recovery planning support a release decision.
Keep file and agent access tied to the right work
The current files, SFTP and agent-access guide distinguishes file-transfer credentials from shared agent access. From the selected website, the SFTP control leads to connection management in Account. Choose the exact permitted resource and environment before using its separate file-transfer details.
For an agent connection, Manage agent access leads to Account’s shared agent-token management. The agent can then list the resources your identity is permitted to use. Opening a Nexus website does not issue a new token. In addition, the available access follows the current permitted projects, workspaces and services.
Keep those connection details private and give an agent a clear task, target and expected result. Also distinguish browser sign-out from token revocation: the guide explains that signing out of the browser does not revoke an agent token. For the broader permission and untrusted-content questions, read our MCP security guide.
Manage game servers and broader infrastructure deliberately
A game-server assignment gives the responsible person a route to the selected server’s state and supported controls. First, inspect the console, files and configuration. Then use the appropriate power, settings, schedule or backup operation. Finally, read the completion state and console output before starting another action. The game-server guide follows this sequence.
Recovery, reinstall and configuration work can affect a community’s saved state. Therefore, establish the exact target and recovery point before a replacement. A useful operating brief identifies the server, intended change, material to preserve and result to verify. Players can continue to use the game’s own access system.
Broader infrastructure views serve a different level of responsibility. They can cover system services, processes, machines, storage or networking where the role permits. However, the effect of a change may extend beyond one website. Check the resource and its dependencies before treating a system-wide control as a fix for a single application.
Know what a backup or recovery action actually covers
A recovery point is useful when it contains the material you need and the restoration scope is understood. Before replacing website or game state, preserve a usable predecessor and confirm where it is stored. The roles and backups guide connects those checks to the intended resource.
Nexus also distinguishes browsing a recovery point, recovering a separate copy and restoring an eligible individual file. These actions produce different outcomes. For example, a separate recovered copy still needs inspection and does not imply that live material was replaced. The backup browsing and file-recovery guide explains the available steps and limits.
For a file restore, review the selected path, recovery point and current-file predecessor before the permitted replacement. Then inspect the final operation, restored file and affected application. Some file types or protected locations can be excluded from an individual-file action. If the scope is unclear, resolve it with the infrastructure administrator before proceeding.
Check the result of an operation
Operations, Monitoring, System logs and Audit trail answer different questions. Operations records an action’s execution result. Monitoring provides resource measurements over the displayed period. System logs can provide recent journal information, while the audit trail records the actor, target and outcome. Access to each view depends on permissions.
After a change, verify the affected service in its ordinary application or resource view. A request accepted by the panel still needs a completed outcome. Likewise, a timeout leaves the result uncertain until the current operation and target state are checked. The operations and monitoring guide provides a useful way to investigate that uncertainty.
When requesting help, include the resource, approximate time, operation reference and relevant error with private details removed. Keep unrelated logs, customer records and connection secrets out of the report. This gives the administrator enough context to investigate the intended action and preserve successful work.
Where Yasa Nexus fits in the ecosystem
Nexus provides infrastructure administration within the wider Yasa Ecosystem. Yasa is the starting point for website and digital-service work. Hercules provides a project workspace, while Midas supports invoice preparation. Account manages shared identity and settings, and Help explains product workflows.
For example, a website team can plan its work in Hercules and use Nexus for the assigned hosting operation. Each application still applies its own session and permissions. Therefore, sharing a Yasa identity helps the person move between services while keeping project collaboration and infrastructure control separate.
You can start with the hosting need in front of you: a business website, an environment for a planned change or a game server for a community. Yasa Nexus brings the relevant administration together, with access arranged for the people responsible for that work. The required resources and commercial terms are agreed for the actual service.
Arrange the right hosting and access
Tell us what you want to host or which existing resource you have been asked to manage. Include the intended website or server and who needs access, while keeping passwords and tokens private. Contact Yasa to discuss the hosting setup or arrange the appropriate invitation.
