CrescoDB 部署後的下一步：生產監控與更清晰的入門途徑

Beyond Deployment: What's Next for CrescoDB, Plus a Clearer Path to Getting Started
Building a backend is only part of the work.
You define your data, build your API, connect your application, test it, and eventually deploy it. Your application is live. Your users can access it. Everything appears to be working.
Then something breaks.
A route begins returning server errors. A query becomes unexpectedly slow. Your server starts running out of disk space. Your application stops responding, and you don't notice until someone reports it.
The problem isn't necessarily that something broke. Software breaks. The problem is finding out what happened, identifying where it happened, and getting enough information to fix it.
That's the next part of the developer experience we're working on at CrescoDB.
Our upcoming update focuses on production monitoring and the operational visibility developers need after deployment. We're also working to make CrescoDB's own getting-started experience clearer, because we've made that journey more confusing than it should be.
Here's what's changing, why it matters, and how to get a project running in the meantime.

1. The next stage: understanding what happens after deployment We've been building CrescoDB around the backend workflow: creating your data models, generating an API, adding authentication, verifying access rules, and deploying to infrastructure you control. But a backend doesn't stop being your responsibility when it goes live. Once an application is in production, you need answers to questions like:
2. Which endpoint is returning errors?
3. Are requests getting slower?
4. Which database queries are taking the longest?
5. Is the server running low on memory or disk space?
6. Is the application actually reachable by users?
7. If something fails, will you know before a user has to tell you? Without monitoring, answering those questions can involve manually checking logs, connecting to servers, running commands, and trying to reconstruct what happened after the fact. We're working to make that process less painful. Application monitoring The monitoring capabilities we're preparing are designed to give developers visibility into their application's behavior, rather than simply reporting whether the application process is running. That includes information about:
8. Requests and errors grouped by route.
9. Server and client error rates.
10. Request latency, including p95 latency.
11. Slow database queries and query failures.
12. Application errors with useful debugging information.
13. Runtime indicators such as memory usage and event-loop delay. For example, imagine that a store's checkout endpoint starts returning server errors while the rest of the application continues working. A generic alert saying "your application has an error" leaves you with more questions. Knowing that POST /checkout is failing, seeing how many requests were affected, and having information to investigate the failure gives you a much more useful starting point. The goal is not to replace debugging. It's to help you find the right place to begin. Server monitoring Application health and server health are related, but they're not the same thing. An application can encounter problems because of its own code. It can also encounter problems because the machine running it is under pressure. We're expanding the visibility developers have into the infrastructure supporting their applications, including:
14. CPU usage and system load.
15. Available memory and swap.
16. Disk usage and partitions.
17. Running containers and their resource usage.
18. Server availability.
19. Operational problems that may require attention. Consider a server whose disk is nearly full. That can interfere with deployments, backups, and database operations. Finding out only when a deployment fails is much later than finding out while there's still time to act. The idea is to make those conditions visible before they turn into a larger incident. Uptime checks from outside the server Monitoring an application from inside its own process is useful, but it cannot tell you everything a visitor experiences. A server might be running while its public domain is misconfigured. A certificate might have a problem. A CDN might be returning an error. A URL might be reachable but taking too long to respond. That's why external uptime checks matter. CrescoDB's monitoring direction also includes checking public URLs from outside the server, helping identify problems involving reachability, DNS, TLS, response times, and the page being served. The objective is to see the application from more than one perspective: from inside the app, from the server underneath it, and from the outside where users encounter it. Alerts that tell you when something needs attention Monitoring is less useful if you have to keep a dashboard open all day to benefit from it. Alerts are intended to bring important problems to your attention so you can investigate them. CrescoDB's documented monitoring capabilities include email alerts, with Slack and Telegram available on paid plans. The intention is to help developers respond to meaningful failures without having to watch every metric manually. We're working toward a better operational workflow: detect a problem, understand where it is happening, investigate it, and work toward a resolution. The important distinction is that we're not trying to give developers more numbers to stare at. We're trying to make production problems easier to understand and act on. You can read more about the direction in the current CrescoDB product overview and production monitoring documentation.
20. Deployment is part of the workflow, not the end of it We've also been thinking about the steps between a working local project and a working production application. Developers have different workflows. Some prefer Git-based deployment. Others want to deploy an existing project without setting up a repository workflow first. We're working on reducing friction in that process, including ZIP-based deployment and better ways to manage disk allocation when multiple applications share a server. The goal is to make deployment more accessible without hiding the important decisions from developers. CrescoDB is built around the idea that you should be able to run your application on infrastructure you control. Your code and data shouldn't become inaccessible simply because you decide to change platforms. That means deployment should be understandable, operational problems should be easier to diagnose, and leaving the platform should remain a practical option. We're not going to pretend that every part of this workflow is finished. We're continuing to improve it.
21. We also owe you an apology Before talking about more features, we need to acknowledge something about the current product experience. Our homepage and onboarding instructions have been confusing, and we're sorry. We've tried to communicate a lot about CrescoDB: local development, the database and API, authentication, the dashboard, AI assistance, deployment, and the operational tools around production. Those capabilities matter. But presenting them without making the starting point obvious can leave a new developer wondering what to do first. Some of the important distinctions haven't been clear enough:
22. What you need to install.
23. How to create and run a local project.
24. Which features work locally.
25. When you need an account.
26. What changes when you want to deploy.
27. How to connect your project to a server you control. We should have made those steps easier to follow. A developer who wants to try CrescoDB shouldn't have to study the entire product before getting a working API. They shouldn't have to confuse local development with cloud deployment, either. That's a communication and onboarding problem, and it's our responsibility to address it. We're working to make the homepage more focused and the getting-started journey more direct. In the meantime, here's a practical guide you can follow.
28. How to get a CrescoDB project running You do not need to deploy to a server to begin using CrescoDB. For local development, the prerequisites are straightforward: install Node.js 20 or newer, then install CrescoDB. Step 1: Install Node.js CrescoDB requires Node.js 20 or newer. Node.js 22 LTS is the recommended starting point. Check your installed version: node --version

If you need to install Node.js, use the official installer or a version manager.
Step 2: Install CrescoDB
Install the CLI globally:
npm install -g crescodb

You can also use npx crescodb if you prefer not to install it globally.
Step 3: Create a project
Create a new folder for your project, move into it, and initialize CrescoDB:
mkdir my-project
cd my-project
cresco init

This creates the basic project files, including the schema, configuration, and local SQLite database.
Important: A new project starts empty. That is intentional. You define your own tables and data models rather than being given a pre-populated application.
If you would rather start with demo tables, initialize a starter project instead:
cresco init --starter

Use one initialization option or the other for a new project.
Step 4: Start the development server
From your project directory, run:
cresco dev

CrescoDB starts the local REST API and development dashboard.
Step 5: Open the dashboard
Visit:
http://localhost:3000/studio
From the dashboard, you can browse and edit data, design your schema, run SQL, inspect your models, and explore the project as you build it.
You now have a local project to work with.
You do not need a rented VPS, a cloud account, or Docker simply to reach this stage.
Step 6: Add your data models
Your project starts empty unless you chose the starter option.
You can define tables through the schema file, use the dashboard's schema editor, or describe the data you want to create through the supported AI workflow.
For example, a simple blog might need models for posts and comments. A store might need products and orders.
Once your schema is in place, CrescoDB can generate the corresponding API.
You can then use those endpoints from your frontend or another application over HTTP.
Step 7: Add authentication and verify access rules
When your application needs authentication, you can generate the authentication code:
cresco create auth

CrescoDB writes editable code into your project rather than requiring you to treat authentication as an opaque black box.
Before deployment, you can also run:
cresco audit

This checks access rules against your schema and identifies critical exposure issues. CrescoDB's deployment workflow also runs the audit before preparing a deployment, refusing to proceed when it finds a critical issue unless you explicitly override it.
Step 8: Deploy when you're ready
Local development and production deployment are separate stages.
Once your application is working locally, you can move on to deployment. CrescoDB supports deploying to a server you control, with a workflow for connecting the server, deploying the project, and configuring a domain.
You don't have to do this before you can start building.
For the deployment steps, use the official guide to deploying to your own server rather than trying to infer the process from the homepage.
The full local quickstart is available in the CrescoDB getting-started guide.

1. What we're trying to build with CrescoDB We don't want CrescoDB to be just another way to generate an API. We want the workflow to make sense from the first local project through production:
2. Build: Define your data and get a working backend.
3. Verify: Check access rules before deploying.
4. Deploy: Run your application on infrastructure you control.
5. Monitor: Understand application errors and server health.
6. Operate: Manage the ongoing work of keeping an application healthy.
7. Own: Retain control over your code and data. These parts are connected. A project that runs locally but is difficult to deploy has an incomplete workflow. An application that deploys successfully but provides no useful operational visibility creates a different problem. And a platform that makes it difficult to leave isn't giving developers full control. We're working on these parts together because they affect the experience of building and maintaining real software.
8. What's next? Tomorrow, we're sharing the next CrescoDB update, with a focus on production monitoring and the visibility developers need after deployment. We're also continuing to improve deployment workflows and address the confusion around getting started. We'll keep sharing what we're building, explaining what has changed, and listening to the developers using the product. We know that shipping features isn't the only measure of progress. The product needs to be understandable, the documentation needs to be useful, and the path from trying CrescoDB to building something real needs to be clear. We've got work to do on that, and we're taking it seriously. Thank you to everyone who has tested CrescoDB, shared feedback, reported problems, or followed the project while it's evolving. We're building this in public, including the parts we need to get better at. Stay tuned for tomorrow's update. Explore CrescoDB: CrescoDB official website Get started: CrescoDB quickstart