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:

• Which endpoint is returning errors?

• Are requests getting slower?

• Which database queries are taking the longest?

• Is the server running low on memory or disk space?

• Is the application actually reachable by users?

• 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:

• Requests and errors grouped by route.

• Server and client error rates.

• Request latency, including p95 latency.

• Slow database queries and query failures.

• Application errors with useful debugging information.

• 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:

• CPU usage and system load.

• Available memory and swap.

• Disk usage and partitions.

• Running containers and their resource usage.

• Server availability.

• 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.

1. 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.

2. 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:

• What you need to install.

• How to create and run a local project.

• Which features work locally.

• When you need an account.

• What changes when you want to deploy.

• 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.

1. 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. 5. 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:

• Build: Define your data and get a working backend.

• Verify: Check access rules before deploying.

• Deploy: Run your application on infrastructure you control.

• Monitor: Understand application errors and server health.

• Operate: Manage the ongoing work of keeping an application healthy.

• 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.

1. 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

Your code lives in a repository, changes can be tracked, and deployments can follow a branch or commit. For a team shipping continuously, that workflow makes sense.

But not every deployment begins with a Git repository.

Sometimes you already have a project folder you want to ship. Sometimes you're working with an exported project, a prototype or an application that isn't connected to a deployment repository.

In those situations, requiring Git to be the only entry point can add unnecessary friction.

That's why we're adding ZIP deployment to CrescoDB.

An additional way to deploy

CrescoDB already supports GitHub-based deployment workflows, including deployment to your own VPS and supported managed platforms.

ZIP deployment adds another option: upload an application archive and use it as the starting point for deployment.

The important distinction is that ZIP deployment complements the existing workflow. It doesn't replace Git.

Git remains valuable when you need version history, code review, collaboration and repeatable deployments tied to repository changes.

A ZIP-based workflow is useful when the project is ready to deploy but the repository isn't the most convenient starting point.

The best deployment method depends on how the application is developed and maintained.

The next question: where should the application run?

For developers using a VPS, deployment is only one part of the problem.

A server has finite resources. Disk capacity, memory, CPU and network capacity all have limits.

As you deploy more applications onto the same server, you need to think about how those applications are organized and how available storage is allocated.

That's where custom server partitioning comes in.

Allocate disk space across multiple apps

With CrescoDB's custom partitioning, you can divide available server disk space into separate app spaces rather than treating every deployment as one undifferentiated storage area.

For example, imagine you have a VPS with 100GB of disk space.

You might choose to allocate that capacity across:

• Two app spaces

• Three app spaces

• Four app spaces

The allocation is subject to the minimum partition size supported by the platform.

This gives you more control over how the server's available disk capacity is distributed across deployments.

Each app gets its own allocated space, helping prevent one deployment's storage from colliding with another's.

The exact allocation depends on your applications' needs. An app storing uploaded media may need more disk space than a small API with very little persistent data.

The goal is flexibility without pretending that a server has unlimited capacity. Partitioning allocates the disk space available; it doesn't create additional capacity.

Why this matters for small projects

A developer might have several small applications that don't each justify a separate VPS.

Being able to run multiple applications on one server can be practical, provided the deployment workflow and resource allocation are managed carefully.

Instead of immediately provisioning another server for every small project, you can decide how to organize the capacity you already have.

Of course, disk allocation is only one part of server management. CPU, memory, networking, security and application-level configuration still matter. Partitioning doesn't remove the need to manage those resources appropriately.

But it gives developers another useful control over how their deployments are arranged.

Deployment is part of a larger lifecycle

At CrescoDB, we're thinking beyond the act of getting code onto a server.

The wider workflow includes building the application, owning the infrastructure and data, verifying readiness, deploying, operating and monitoring the running system.

That's why our six pillars are:

Build → Own → Verify → Deploy → Operate → Monitor

ZIP deployment improves how developers can get an application into the workflow. Custom partitioning adds flexibility when organizing multiple applications on a VPS. Monitoring helps developers understand the health of their applications and the servers underneath them.

These are connected problems, not isolated features.

Try the updated workflow

We're adding ZIP deployment and custom server partitioning alongside CrescoDB Monitor, which brings application and server monitoring together with alerts through email, Slack and Telegram.

If you're building applications and managing your own infrastructure, take a look at CrescoDB:

https://crescodb.com

How do you currently deploy projects that aren't connected to a Git repository? And when running several applications on one VPS, how do you organize storage across them?

I've started thinking about it the other way around.

Sometimes I don't realize how poorly I understand something until I try to explain it.

You can spend hours working with a piece of technology and feel completely comfortable with it.

Then somebody asks:

Why does it work that way?

And suddenly your brain goes:

Well… it just does.

That's usually the point where you discover the difference between recognizing something and actually understanding it.

Code lets you hide behind working software

Programming has an interesting loophole.

Your code can work even when your mental model is incomplete.

You can know that:

await db.query(...)

works.

You can know where to put it.

You can know how to handle the response.

But that doesn't necessarily mean you understand:

what happens when the connection drops how the connection pool behaves when the promise resolves what happens under concurrent requests how the database handles the query what failure actually looks like

And that's fine.

Nobody needs to understand every abstraction underneath every line of code they write.

But the gaps become obvious when you attempt to explain the system to another person.

Writing removes the autocomplete from your understanding.

Explaining something forces you to find the missing pieces

Let's say I want to write:

"A database connection pool improves performance."

Easy sentence.

Then I ask myself:

Why?

Because we're reusing connections instead of creating one for every request.

Okay.

Why is opening a new database connection expensive?

Now we're talking about networking, authentication, resource allocation and connection setup.

What happens if the pool is exhausted?

What decides how many connections should exist?

Can too many connections make performance worse instead of better?

Five minutes ago I thought I was writing one paragraph.

Now I'm reading PostgreSQL documentation.

That's what I like about writing.

It exposes the edges of what you actually know.

Tutorials are especially unforgiving

When you're coding alone, you can skip steps mentally.

You know that before this:

npm run dev

you already:

npm install

created .env, configured the database and probably fixed three errors you no longer remember.

The reader doesn't know any of that.

So when you're writing a tutorial, you have to reconstruct the real sequence.

That forces you to think more carefully about:

dependencies assumptions defaults edge cases setup failure states

You begin noticing complexity you've learned to ignore.

I've had several situations where writing about a workflow made me think:

Why does this require so many steps in the first place?

Which is also where product ideas tend to appear.

Writing is surprisingly good product research

This one wasn't obvious to me initially.

When you try to explain a technical problem properly, you naturally start researching how other developers solve it.

Suppose I'm writing about deploying a backend.

I might start with:

"Deploying a backend requires…"

Then I need examples.

So I start looking at:

Docker Railway Render VPS deployments CI/CD migrations reverse proxies environment management health checks

And while reading, patterns start showing up.

Everyone has slightly different solutions to the same underlying problems.

You start noticing where tools overlap.

Where workflows are unnecessarily complicated.

Where developers complain.

Where documentation repeatedly has to explain the same thing.

You weren't doing market research.

You were trying to write a decent article.

But you end up learning a lot about the market anyway.

Writing also generates ideas

One article tends to create five more.

You start writing about logging.

Then you realize error reporting deserves its own article.

That leads to observability.

Then production debugging.

Then distributed tracing.

Then suddenly you have a backlog of topics you didn't have yesterday.

It's basically recursion for ideas.

The most useful part is that the ideas aren't coming from:

"What should I post today?"

They're coming from questions you naturally encountered while trying to understand something.

Those tend to make better articles.

It changes how you read documentation

Before I started writing more often, documentation was usually transactional.

I had a problem.

I searched for the answer.

I copied the relevant mental model into my brain.

Then I left.

Now I notice more things.

Why did the documentation explain this concept before that one?

What misconception are they trying to prevent?

Why is this warning here?

What edge case was common enough that somebody decided it deserved an entire section?

Good technical documentation isn't only teaching you the technology.

It's showing you where people usually misunderstand it.

That information is incredibly useful.

It makes vague opinions harder to keep

Developers have plenty of opinions.

"This framework is slow."

"Microservices are overkill."

"SQL is better."

"Serverless is expensive."

"X is easier than Y."

Those opinions are easy to say.

They're much harder to publish when you know another developer can ask:

Based on what?

Writing forces you to qualify things.

Instead of:

Serverless is expensive.

You start writing:

Serverless can become expensive for workloads with these characteristics…

Which is a much better statement.

You stop trying to sound certain and start trying to be accurate.

That's useful far beyond writing.

You don't have to become a "content creator"

This is probably the part developers hate.

The moment somebody says:

You should write.

it starts sounding like:

Build your personal brand. Post three times every day. Optimize engagement.

I'm not talking about that.

You can write once a month.

You can have 20 readers.

You can publish something that gets absolutely no traction.

The value isn't only distribution.

The process itself is useful.

You are forcing your brain to turn:

I think I understand this

into:

Here is exactly how I think this works.

Those are very different things.

The simplest writing habit I've found

When something makes me stop while coding, I write it down.

That's it.

Things like:

Why did this migration fail?

Why does this API behave differently in production?

Why are these two tools solving the same problem differently?

Why does this configuration exist?

What actually happens when this command runs?

You don't need the article immediately.

Just keep the questions.

When you eventually sit down to write, you're not staring at a blank editor trying to invent a topic.

You're answering something that genuinely made you curious.

And curiosity is usually a better starting point than a content calendar.

Writing is part of learning

I used to think the sequence was:

Learn → understand → write

Now I think it's closer to:

Learn → write → discover what you don't understand → learn more → rewrite

And the loop keeps going.

The article is almost a side effect.

The real output is a clearer mental model.

So if you're learning something, building something or repeatedly solving the same technical problem, try writing about it.

Even if nobody reads it.

You'll probably discover something you didn't know you didn't know.

The API responds correctly.

The database connection works.

Authentication passes.

You run the app locally for the tenth time and everything looks fine.

Then someone says:

“Cool. Let’s deploy it.”

And suddenly the problem changes completely.

A backend that works on your laptop is not necessarily a backend that is ready for production.

Local development proves that your application can run in your environment.

Production asks a much harder question:

Can this thing keep working when the environment is no longer under your control?

That difference is where a lot of small teams get caught.

Local development hides a lot

Your development machine is unusually forgiving.

You probably have:

the correct environment variables direct access to the database the right runtime installed every dependency available full filesystem permissions a predictable network logs directly in your terminal one developer making requests a database you can reset without consequences

Production gives you none of those guarantees.

The application now needs to survive restarts, failed migrations, missing secrets, expired credentials, network interruptions, disk limits, bad deployments and actual users.

That means “it runs locally” is only the beginning.

1. Configuration becomes infrastructure

Locally, this might be enough:

DATABASE_URL=postgresql://localhost:5432/app JWT_SECRET=dev-secret PORT=3000

In production, configuration has consequences.

What happens if JWT_SECRET is missing?

Does the application refuse to start?

Or does it silently fall back to something unsafe?

What happens when:

process.env.DATABASE_URL

is undefined?

A production backend should fail predictably.

For example:

const required = [ "DATABASE_URL", "JWT_SECRET" ];

for (const variable of required) { if (!process.env[variable]) { throw new Error( Missing required environment variable: ${variable} ); } }

It is simple, but it is much better than discovering the problem after deployment.

Configuration should be validated before the application begins accepting traffic.

1. Database migrations stop being harmless

During development, database changes are easy.

Something breaks?

Reset the database.

Change the schema.

Run the migration again.

Move on.

Production is different because the database contains data you cannot casually destroy.

Imagine changing:

ALTER TABLE users DROP COLUMN username;

locally.

No big deal.

Now imagine doing that with 50,000 production users and discovering another part of the application still depends on username.

The migration technically succeeded.

The deployment still failed.

Production migrations need to consider:

backwards compatibility existing data rollback strategy application version compatibility long-running operations database locks

For risky changes, the safer pattern is often incremental.

Instead of:

remove old field deploy new code hope

you might:

add new field deploy compatible code migrate data verify remove old field later

The boring version is usually the safer version.

1. “The server is running” is not a health check

Your process can be alive while your application is effectively dead.

Maybe:

PostgreSQL is unreachable Redis is unavailable migrations failed storage credentials are invalid an external dependency is timing out

Your process manager may still happily report:

RUNNING

That is why production systems usually need an actual health endpoint.

A simple example:

app.get("/health", async (req, res) => { try { await db.query("SELECT 1");

res.status(200).json({
  status: "healthy"
});

} catch { res.status(503).json({ status: "unhealthy" }); } });

Now your infrastructure has something meaningful to test.

Not:

Is Node.js still running?

But:

Can this application actually serve requests?

That distinction matters.

1. Logging changes when nobody is watching the terminal

During development:

console.log(error);

often feels perfectly adequate.

You are already looking at the terminal.

Production errors usually happen while nobody is looking.

And this:

Something went wrong

is almost useless three hours later.

Useful production logs should tell you things like:

what happened when it happened which request triggered it which service failed how severe the failure was

Structured logs are much easier to search and process.

Instead of:

console.log("Database error");

something closer to:

logger.error({ event: "database_connection_failed", requestId, error: error.message });

gives you something you can actually investigate.

Production observability is not about printing more text.

It is about leaving enough evidence to understand failures after they happen.

1. Backups do not matter until restoration works

A lot of systems technically have backups.

Far fewer know whether those backups can actually be restored.

There is an uncomfortable difference between:

“We create a backup every night.”

and:

“We successfully restored yesterday’s backup into a clean database.”

The second statement proves something.

The first only proves that a file exists somewhere.

A production backup strategy should answer:

How often do backups run? Where are they stored? How long are they retained? Are they encrypted? How quickly can they be restored? When was restoration last tested?

A backup you have never restored is still partly a hypothesis.

1. Deployment without rollback is a one-way door

Imagine deploying version 1.8.

Ten minutes later:

error rates spike users cannot authenticate database queries slow down one endpoint starts returning 500

What happens next?

If the answer is:

“Give me twenty minutes while I fix it.”

you do not really have a recovery strategy.

Sometimes the fastest fix is simply returning to the last known-good version.

That requires your deployment system to know:

v1.6 v1.7 v1.8 ← current

and to make returning to:

v1.7

boring.

Production reliability is not about never breaking anything.

Eventually something will break.

Reliability is largely about reducing how expensive failure becomes.

1. Production traffic exposes assumptions

During local development you might be the only user.

Production introduces:

User 1 User 2 User 3 ... User 10,000

And all of them can do things at inconvenient times.

You start encountering problems like:

race conditions exhausted database connections duplicate requests slow queries rate abuse concurrent writes memory growth unexpectedly large payloads

For example, this query may seem harmless:

SELECT * FROM orders;

until orders contains several million records.

Production has a habit of turning assumptions into benchmarks.

A better definition of “done”

For a backend feature, “done” should probably not mean:

✓ Works locally

A stronger checklist is closer to:

✓ Works locally ✓ Configuration validated ✓ Database changes are safe ✓ Authentication and permissions verified ✓ Health checks available ✓ Errors observable ✓ Deployment reproducible ✓ Backups exist ✓ Restoration tested ✓ Rollback possible ✓ Production behavior monitored

Not every side project needs enterprise infrastructure.

But every application should know what level of failure it is prepared to tolerate.

That is the important part.

The backend lifecycle is bigger than building

Developers spend a lot of time discussing how quickly we can create APIs, databases and authentication.

Those things matter.

But building the backend is only one stage.

Eventually the lifecycle becomes:

Build → Verify → Deploy → Operate → Own

And the transitions between those stages are where a surprising amount of engineering time disappears.

That is also the problem we have been thinking about while building CrescoDB: how to give smaller engineering teams a cleaner path through the backend lifecycle without forcing them to stitch together an increasingly complicated production stack.

But regardless of which tools you use, the principle stays the same:

A backend isn't production-ready because it runs. It's production-ready when you understand how it fails.