# Rake assets:precompile without database
**URL:** https://meta.discourse.org/t/rake-assets-precompile-without-database/126779
**Category:** Self-hosting
**Created:** [August 25, 2019, 3:50pm UTC](https://meta.discourse.org/t/rake-assets-precompile-without-database/126779 "2019-08-25T15:50:10Z")
**Posts on this page:** 14
**Page:** 1
### Author:  [@matpen](https://meta.discourse.org/u/matpen)
#### Post date: [August 25, 2019, 3:50pm UTC](https://meta.discourse.org/t/rake-assets-precompile-without-database/126779/1 "2019-08-25T15:50:10Z")
I noticed that the task rake assets:precompile requires a database connection: this means that the task can only be run at “run time” (after deployment) as opposed to “build time” (while building the container image). Since the task is very expensive in terms of running time, this can be annoying.
Not being a Ruby/Rails developer, I did some research and found that this behavior could be [disabled](https://stackoverflow.com/a/8997640/1229582) until Rails 4, and afterwards developers have been resorting to some hacks (null database connection). The latter of course requires intimate knowledge of the application, in order to avoid breaking anything.
While searching for a better solution I found [this commit](https://github.com/discourse/discourse/commit/7429700389191e49292a2164b069cb57877c2871) which seems similar in spirit. So my questions are:
- are the developers already working on the matter, or are there technical reasons why this cannot be done?
- if some parts of the task indeed require the database connection, would it be feasible to split the task into two (or more), so that some work (e.g. compiling locales, minifying JS and CSS) can be done at build time?
- is there a known workaround at this moment (e.g. “null database” as mentioned above)?
---
### Author:  [@Falco](https://meta.discourse.org/u/Falco)
#### Post date: [August 25, 2019, 4:02pm UTC](https://meta.discourse.org/t/rake-assets-precompile-without-database/126779/2 "2019-08-25T16:02:39Z")
> [@matpen](#):
>
> if some parts of the task indeed require the database connection
We store the themes in the database (they are edited in the admin UI) so the CSS is inside PostgreSQL so you need the database connection at build time to be able to precompile those.
---
### Author:  [@matpen](https://meta.discourse.org/u/matpen)
#### Post date: [August 25, 2019, 5:15pm UTC](https://meta.discourse.org/t/rake-assets-precompile-without-database/126779/3 "2019-08-25T17:15:52Z")
> [@Falco](#):
>
> We store the themes in the database (they are edited in the admin UI) so the CSS is inside PostgreSQL so you need the database connection at build time to be able to precompile those.
Thank you for the information!
Would it be thinkable to implement the build of locales separately (to be run at build time)?
Also, I can imagine that some environments (it is so for me at least) might not want to allow changing themes: would it be possible to provide an alternative storage for CSS in this case?
---
### Author:  [@Falco](https://meta.discourse.org/u/Falco)
#### Post date: [August 25, 2019, 5:55pm UTC](https://meta.discourse.org/t/rake-assets-precompile-without-database/126779/4 "2019-08-25T17:55:58Z")
We did discuss the idea of a switch that would disable the whole Customization UI, allowing the CSS files to be compiled in build time and uploaded to object storage during build (aka the same as the JS core / plugins).
However, that is a _very_ niche case, that would only appeal to enterprise-y deployments while providing zero value to 99% of the communities on the web. So that isn’t in our roadmap and it is a pretty hard sell to put work on this over developing new features or performance work.
Can you tell us more about your environment and use case?
---
### Author:  [@matpen](https://meta.discourse.org/u/matpen)
#### Post date: [August 25, 2019, 6:58pm UTC](https://meta.discourse.org/t/rake-assets-precompile-without-database/126779/6 "2019-08-25T18:58:09Z")
Good to know that the idea has already been discussed. I do understand that the amount of work for the change is probably too large to be justifiable.
In my case, discourse will be associated to a pre-existing website, so there will be a fixed custom theme to match the one of the website: it would not make sense to change it dynamically.
---
### Author:  [@Falco](https://meta.discourse.org/u/Falco)
#### Post date: [August 25, 2019, 7:11pm UTC](https://meta.discourse.org/t/rake-assets-precompile-without-database/126779/7 "2019-08-25T19:11:56Z")
Oh I meant the use case for you to not be able to connect to the database on “build time”.
---
### Author:  [@matpen](https://meta.discourse.org/u/matpen)
#### Post date: [August 25, 2019, 7:17pm UTC](https://meta.discourse.org/t/rake-assets-precompile-without-database/126779/8 "2019-08-25T19:17:25Z")
Oh: well, when I build the image, I work on my development laptop. The image is then pushed to a repository, and the final system (VPS on DigitalOcean) pulls it from there.
The database sits in a volume on the VPS, so it cannot be updated on my laptop: this would require me to stop discourse, rsync the database to my laptop, build and push the image, and finally restart discourse…
---
### Author:  [@Falco](https://meta.discourse.org/u/Falco)
#### Post date: [August 25, 2019, 7:47pm UTC](https://meta.discourse.org/t/rake-assets-precompile-without-database/126779/9 "2019-08-25T19:47:00Z")
So you are running the database and the application all inside one droplet?
In that case sticking with our [official install guide](https://github.com/discourse/discourse/blob/master/docs/INSTALL-cloud.md), which results in a droplet with application and database in the same droplet will give you a fully functional site, that can be updated from the web interface and optionally from the command line with a full image rebuild.
---
### Author:  [@matpen](https://meta.discourse.org/u/matpen)
#### Post date: [August 25, 2019, 7:59pm UTC](https://meta.discourse.org/t/rake-assets-precompile-without-database/126779/10 "2019-08-25T19:59:53Z")
> [@Falco](#):
>
> So you are running the database and the application all inside one droplet?
If by this you mean “directly on the host”, then no. They are running in a container, specifically a `podman` container. Ideally, I would split the container into multiple ones (one for discourse, one for postgres, one for redis…) but this connects with the issue that we are discussing, so I am still unsure on the proper course of action.
> [@Falco](#):
>
> that can be updated from the web interface and optionally from the command line with a full image rebuild
Seems unsafe to me. I generally test the containers in my development environment before deploying to production. Further, ideally containers should be read-only.
---
### Author:  [@Falco](https://meta.discourse.org/u/Falco)
#### Post date: [August 25, 2019, 8:08pm UTC](https://meta.discourse.org/t/rake-assets-precompile-without-database/126779/11 "2019-08-25T20:08:48Z")
> [@matpen](#):
>
> If by this you mean “directly on the host”, then no. They are running in a container, specifically a `podman` container. Ideally, I would split the container into multiple ones (one for discourse, one for postgres, one for redis…) but this connects with the issue that we are discussing, so I am still unsure on the proper course of action.
You can split those containers and then run the image bootstrap process in another, short-lived droplet. Since droplets are charged hourly that will be cheap. You can even leverage droplet private networking between the database container host and the “build” container host.
---
### Author:  [@matpen](https://meta.discourse.org/u/matpen)
#### Post date: [August 25, 2019, 8:16pm UTC](https://meta.discourse.org/t/rake-assets-precompile-without-database/126779/12 "2019-08-25T20:16:30Z")
Hehe, thank you for the idea, but that starts to be complicated. Furthermore, it wont solve the problem, because we still have to stop discourse and wait for the bootstrap process, or there might be inconsistent data.
Seems like we will need to live with a long downtime (5-6 minutes for migration and precompilation) on upgrade. Still, I would appreciate if you guys could keep a low-priority issue in the tracker, maybe with a link to this topic.
Thank you, and keep up the good work!
---
### Author:  [@codinghorror](https://meta.discourse.org/u/codinghorror)
#### Post date: [August 25, 2019, 8:24pm UTC](https://meta.discourse.org/t/rake-assets-precompile-without-database/126779/13 "2019-08-25T20:24:11Z")
> [@matpen](#):
>
> Seems like we will need to live with a long downtime (5-6 minutes for migration and precompilation) on upgrade
No this is not the case.
> [@Faster rebuilds?](https://meta.discourse.org/t/faster-rebuilds/40341/2):
>
> If rebuild time is a huge concern to you I would strongly recommend running a dedicated data container
>
> That way you can bootstrap while your existing site is up and running, meaning you only deal with a few seconds of outage when upgrading via launcher
Should only be “a few seconds” versus 5-6 minutes, but you need dedicated data and web containers. It depends what you want to prioritize.
Also per benchmarks rebuilding [on a fast server](https://meta.discourse.org/t/how-much-is-discourse-affected-by-a-faster-cpu/58407/37) should be ~3 minutes.
---
### Author:  [@matpen](https://meta.discourse.org/u/matpen)
#### Post date: [August 25, 2019, 8:30pm UTC](https://meta.discourse.org/t/rake-assets-precompile-without-database/126779/14 "2019-08-25T20:30:23Z")
Good to know, thank you. In this case, I will definitely split the containers, which is a better architecture anyway.
However, I fail to see how this makes a difference? If I am not mistaken, all containers will share all host CPUs (unless configured otherwise), so processes should be run in parallel in both cases. Am I missing something?
---
### Author:  [@michaeld](https://meta.discourse.org/u/michaeld)
#### Post date: [August 25, 2019, 8:50pm UTC](https://meta.discourse.org/t/rake-assets-precompile-without-database/126779/15 "2019-08-25T20:50:26Z")
Your old container will be running while the new one is bootstrapping. Then you can quickly switch off the old one and start the new one, so downtime will be shorter.