s&box Cloud Storage Comparison

# s&box Cloud Storage Comparison

Network Storage is a backend-as-a-service built specifically for s&box games. General platforms like PlayFab, Supabase, Firebase, Steam Remote Storage, or a custom API can work, but they usually require more authentication glue, REST wrapper code, database schema work, hosting, and deployment maintenance.

Use this page to decide which storage approach fits your s&box project.

## Quick Recommendation

| If you are building... | Best fit | Why |
|---|---|---|
| P2P/listen-server s&box game with persistent players | Network Storage | Client library, s&box auth, endpoints, and Game Values are already integrated. |
| Dedicated-server s&box game with trusted server authority | Network Storage + secret-key runtime | Dedicated servers can call protected endpoints while clients keep using public auth flows. |
| A web app or mobile app that happens to share game data | Supabase/Firebase/custom backend | General app platforms have broader non-game features. |
| A large studio backend with existing infra team | Custom backend | Full control is worth the operational cost when you already have staff and deployment pipelines. |
| Only local save files or Steam Cloud file sync | Steam Remote Storage / local saves | Simpler for non-competitive single-player data, but not a server-authoritative economy. |

## Feature Comparison

| Capability | Network Storage | PlayFab | Supabase/Firebase | Custom API | Steam Remote Storage |
|---|---:|---:|---:|---:|---:|
| s&box C# library included | ✅ | ❌ | ❌ | ❌ | ❌ |
| s&box/Steam identity flow | ✅ built in | ⚠️ custom glue | ⚠️ custom glue | ⚠️ you build it | ⚠️ Steam files only |
| Server-side gameplay endpoints | ✅ endpoints/workflows | ✅ cloud scripts/functions | ⚠️ functions required | ✅ if built | ❌ |
| Game balance values editable from dashboard | ✅ Game Values | ⚠️ title data | ⚠️ tables/config | ✅ if built | ❌ |
| Endpoint-only secure collection writes | ✅ | ⚠️ rules/scripts | ⚠️ RLS/rules | ✅ if built | ❌ |
| P2P-friendly auth path | ✅ | ⚠️ custom | ⚠️ custom | ⚠️ custom | ✅ for files |
| Dedicated-server secret-key path | ✅ | ✅ | ✅ | ✅ | ❌ |
| No database hosting to manage | ✅ | ✅ | ✅ | ❌ | ✅ |
| SQL-level custom reporting | ❌ | ⚠️ exports | ✅ | ✅ | ❌ |
| Public file delivery style storage | ❌ for player records | ⚠️ | ✅ | ✅ | ✅ file sync |
| Best for s&box gameplay state | ✅ | ⚠️ | ⚠️ | ⚠️ | ❌ |

## Architecture Differences

| Approach | How writes usually happen | Main risk | Good use case |
|---|---|---|---|
| Network Storage endpoints | Game calls `NetworkStorage.CallEndpoint(...)`; server-side steps validate and write. | You need to model gameplay actions as endpoints rather than raw saves. | Inventories, XP, shops, daily rewards, leaderboards, progression. |
| Direct database/BaaS writes | Client talks to database or generated API with rules. | Rules can become complex and game-specific anti-cheat is hard to express. | Web dashboards, non-game account data, admin tools. |
| Custom API | Client/server calls your API; your code validates and writes to your DB. | You own uptime, deploys, auth, backups, abuse handling, and migrations. | Studio-scale backend with unique requirements. |
| Steam Remote Storage | Game syncs files through Steam. | File ownership is per-user; no authoritative shared economy or cross-player validation. | Single-player preferences, local settings, simple save files. |

## What Network Storage Focuses On

- s&box C# calls instead of manual HTTP boilerplate.
- s&box auth tokens and SteamID checks handled by the sboxcool.com backend.
- Endpoint-only gameplay writes so clients do not directly mutate important fields.
- Game Values for item prices, XP curves, reward tables, and tuning constants.
- Workflows for reusable validation such as `can_afford`, `profile_exists`, or `has_materials`.
- Rate limits and ledger metadata for anti-cheat and economy review.
- Editor sync and YAML Source so teams and agents can review storage definitions in source control.

## Security Model Comparison

| Security question | Network Storage answer | General platform answer |
|---|---|---|
| Can a client claim another SteamID? | s&box auth validates caller identity for public endpoint calls. | You must wire Steam/s&box identity into the provider. |
| Can a client change gold directly? | Use `accessMode: endpoint` and only expose a `buy-item`/`sell-item` endpoint. | You must write database rules or backend functions. |
| Can a client spoof item prices? | Endpoint looks up prices from Game Values server-side. | You must implement equivalent server-side lookup. |
| Can a dedicated server bypass client auth? | Secret-key runtime can call protected endpoints or act on behalf of players. | Possible, but you wire keys, headers, and permissions yourself. |
| Can suspicious value changes be audited? | `_ledger: true`, operation `source`, and `reason` metadata create audit trails. | Depends on provider; often custom logging is required. |

## When Network Storage Is the Right Choice

Use Network Storage when your game needs any of these:

- Player profiles and save slots.
- XP, levels, currencies, or upgrade progress.
- Inventory, shop, crafting, marketplace, or reward systems.
- Server-authoritative validation without running your own backend.
- P2P/listen-server compatibility with a hosted persistence layer.
- Dedicated-server compatibility through secret-key runtime calls.
- Game balance data that designers can tune without rebuilding the game.

## When Another Platform May Be Better

Choose a general platform or custom backend when you need:

- Complex relational analytics over large datasets.
- A non-s&box product with mobile/web-first requirements.
- Heavy custom business logic outside gameplay endpoints.
- Direct SQL access and custom reporting as a primary feature.
- Existing internal backend infrastructure and staff to operate it.

## Example: Inventory Purchase

With Network Storage, the client sends only intent:

```csharp
await NetworkStorage.CallEndpoint( "buy-item", new
{
    itemId = "health_potion",
    quantity = 3
} );
```

The endpoint then validates the authenticated player, looks up `health_potion` in Game Values, checks gold and stack limits, deducts gold, and adds the items. The client never sends the trusted price.

## Bottom Line

Network Storage is not trying to replace every backend platform. It is optimized for the common s&box problem: **persistent, server-validated gameplay data without building and operating a backend from scratch**.

If your main data is s&box gameplay state, start with Network Storage. If your main product is a broader app platform, use a general BaaS or custom backend and integrate s&box separately.